Custom tsconfig.json

[jednano]

What happens or should happen if you import a TS file that has different compiler options? Does/will deno look for a separate tsconfig.json somehow?

[qti3e]

currently, the ts config is hardcoded in runtime.ts
https://github.com/ry/deno/blob/e3926720118f76e4b1352a75e332026e49154f34/runtime.ts#L183-L191

[ry]

@jedmao Deno doesn't have that logic yet - it only uses one built in set of tsconfig. Coming soon.

[jednano]

Sounds like a roadmap item? Perhaps we can discuss and formalize the requirements in this issue and add it to a milestone?

[jednano]

On the surface, I think these are the problems or scenarios that need to be discussed for this issue:

1. If you require a file locally (e.g., import foo from './foo';) then it's probably a safe assumption that we don't need to track down a separate configuration; unless, like ESLint, we want to allow people to scatter different tsconfig.json files throughout their folder structure. This could be useful for testing purposes too.
2. If you require an external file (e.g., import bar from 'http://foo.com/bar.ts';), then this file could be using a separate configuration. The only thing I can imagine working is to look for http://foo.com/tsconfig.json.

Any thoughts on this or better ideas?

[ry]

@jedmao I will deal with it.

[jednano]

@ry just so you know, I'm willing to help where I can. I'd love to contribute to this project.

[ry]

@jedmao Sure - I think the way to get started is to use this function and
https://github.com/Microsoft/TypeScript/blob/1b6d9229f2699b4285e32466818fa0abe925cd49/lib/typescript.d.ts#L3997
Maybe follow how TS-Node does it:
https://github.com/TypeStrong/ts-node/blob/70d68ef487e937c7d0ad4d6384fbe9b820ee51c9/src/index.ts#L462-L490

[jednano]

Looks like findConfigFile maps to https://github.com/Microsoft/TypeScript/blob/b0f039c9e231638bb4d7c5588abbc7d8e7e4408c/src/compiler/program.ts#L4-L9

[zheeeng]

Expect on this improvement. I'm wondering how will the module system handle the external code using path alias:

// https://example.com/ext-pkg/tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "~src/*": ["src/*"]
    }
}

// https://example.com/ext-pkg/index.ts
import foo from '~src/util/b'

[jednano]

@zheeeng if you're publishing a TypeScript library I think you would make sure not to use paths like that.

[zheeeng]

@jedmao For not import module importer(e.g. require.js) in the browser env, developers often use Rollup/Webpack to bundle modules and provide a .d.ts declarations entry. The downstream lib could use the lib as js lib + .d.ts. These two pack tools all support path alias. Plz consider this usage and not force modification on them.

[playerx]

@zheeeng I was thinking how to write module imports that will support both, node & deno, and thats brilliant idea using tscofnig paths it can be done very easily, in future I already plan to organize code so to support both platforms (until there will be stable version of deno) and I think supporting paths is very important

[jednano]

The thing that concerns me is that tsconfig.json doesn't work the same as package.json in that you can have a tsconfig.json in a totally different directory and use that one to compile project files, even if a tsconfig.json file exists in their own respective directories. As such, we can't assume that a tsconfig.json file in the same folder as foo.ts is actually the right tsconfig.json file.

[Bnaya]

There's upcoming typescript features (3.0ish) to handle build "nested" typescript projects
microsoft/TypeScript#3469 (comment)
microsoft/TypeScript#21706 (comment)

[jednano]

@Bnaya I read that first lengthy post and I'm still not seeing anything that allows you to import a TS file and that TS file tells you where to find the tsconfig.json. Remember that you can have two separate tsconfig.json files that build the same TS file. The only solution I can think of is to put some kind of comment at the top of the TS file, but I'm not loving that idea.

[Bnaya]

importing single ts file, without any metadata, is not a good idea imo.
you must have any manifest file, preferably in the package level

[jednano]

@Bnaya, I agree. That's what I'm trying to figure out here in this thread. Do you have any suggestions that would work? Because currently, it looks like Deno will support single-file imports. I don't think the links you shared solve this problem.

[kitsonk]

I am going to take a look at this now. The compiler has settled down to a point where I think we can start to deal with this.

There are a few approaches that could be taken, and I am not sure which is best:

• We resolve tsconfig.json. If we do this, it will be a little bit problematic, as we will need not allow certain options to be passed to the compiler, as they would cause issues with how the compiler works. So there is a subset of options we can support and maybe even a smaller subset we want to support, so we can test them and make sure they work as expected.
• We create some sort of configuration file, which can operate in lieu of command line arguments and allow us to support the subset of TypeScript compiler options more cleanly. We could try to resolve this file by default at startup (e.g. ${cwd}/deno.json). This could be used for more complex configuration of Deno in the future as well.
• We create individual flags that we pass through to the TypeScript compiler that we would wish to support.

I would want to put the restriction that all modules will be transpiled with the same set of options for that programme. Adjusting it for each one is going to be problematic and confusing to the user.

My feeling at the moment of the only TypeScript compiler options we would want to support are:

Flag	Current Setting	Notes
--allowJs	true	Turning this false would mean that any modules that are JavaScript would throw
--checkJs	true	Turning this false would mean JS would not be type checked and simply "passed through" only transforming the module format if required. Individual modules could opt in via // @ts-check. Currently individual modules can opt out via // @ts-nocheck. This requires --allowJs to be true.
--experimentalDecorators	false	Not sure if we want to support this. It is common in a lot of code, but the current format TypeScript supports does not align with the current TC39 proposal and will be a breaking change when the proposal eventually reaches ratification.
--locale	en-us	The locale to display TypeScript diagnostics in. (Maybe not if the rest of Deno is going to be English at the moment.)
--resolveJsonModule	true once #1065 is resolved	Setting this to false would disallow JSON to be resolved as a module import
--strict	false	While the TypeScript in Deno adheres to the strict module, currently TypeScript code is evaluated in a more "loose" mode. There are a whole set of flags that relate to individual features of strict, but I would suggest we only support --strict.

So that is 6 options we can realistically support out of about 75 options that can be specified in the tsconfig.json (plus also files, excludes, includes which should have no impact on Deno). So I don't think supporting tsconfig.json would be very useful. Considering it is only 6 flags, and if we take out --locale and maybe --experimentalDecorators then that is only 4 flags we need, which makes adding them a bit more realistic.

Also, since we have a default behaviour of true for everything than --strict of the remaining 4, it might make sense to turn them to negatives, like --disallowJs, --noCheckJs, and --noResolveJsonModule.

@ry thoughts?

[kitsonk]

Talking to @ry, we discussed that option 1 listed above is a better approach. Deno will support the tsconfig.json. There are certain compiler options which we cannot support or allow to be modified that have to deal with how code is emitted. When a tsconfig.json provides one of these, we will ignore it, but log out a warning that the option is ignored.

[ry]

Just an update on this issue: We are still heavily refactoring the core compilation infrastructure, so we're putting off adding stuff like that until it solidifies. In particular, we won't attempt address this until #975 is done.

[bartlomieju]

CC @kitsonk can you give an update on this issue?

[kitsonk]

There is still some refactoring churn on the compiler. It is in the queue after that.

[irustm]

@kitsonk what is the status this issue?

[kitsonk]

It is being worked on.