TypeScript "non-standard" compiler options

[blakeembrey]

I just wanted to start by opening a discussion on the options we expose for users and see if we can pick some some common ones together. Maybe too formal and boring to get started, but bear with me.

• compiler Set the compiler (E.g. ntypescript)
  • https://github.com/TypeStrong/ts-node#configuration-options
  • https://github.com/TypeStrong/tsify#options using typescript currently
  • https://github.com/TypeStrong/ts-loader#compiler-string-defaulttypescript
  • https://github.com/TypeStrong/grunt-ts#grunt-ts-gruntfilejs-options
• disableWarnings Disable warnings (not recommended to use, but handy for the REPL)
  • https://github.com/TypeStrong/ts-node#configuration-options
• ignoreWarnings Disable error codes (not recommended to use, but useful for alpha software like Angular 2)
  • https://github.com/TypeStrong/ts-node#configuration-options
• project Set the source directory to read tsconfig.json
  • https://github.com/TypeStrong/ts-node#configuration-options Originally allowed setting configFile, but project is standard and doesn't break the ecosystem
  • https://github.com/TypeStrong/ts-loader#compiler-string-defaulttypescript Currently using configFileName

Please add your own and I'll keep this up to date, and once we close up I can make a module that we can re-use across the compiler repos to normalize this information 😄 Also, if you think one of the above options are wrong or incorrect, definitely point it out 👍

Edit: FWIW, this is awesome - thanks @jbrantly and @smrq for moving your repos, it looks great!

[jbrantly]

ts-loader has an option called transpileOnly which causes it to use TypeScripts transpile API instead of the full-blown language service. This is significantly faster.

gulp-typescript also supports this feature but in a weird way, IMO. Instead of exposing a separate option, it uses the TypeScript option isolatedModules to trigger the mode. I don't think this is correct though since that option is really only meant to put TypeScript into a special error-checking mode. In other words, you should set the isolatedModules TypeScript option if you ever plan to use transpile so that you don't run into problems when you actually do.

In any case, I think it's a useful feature, but I agonized over what to name it and I'm not really happy with it but didn't want to bikeshed anymore.

[basarat]

project

I'd prefer the term tsconfig. I'm working on something that's a bigger scope and using the name tsconfig there makes sense : alm-tools/alm#17

This is the name used by grunt-ts as well : TypeStrong/grunt-ts#202 /cc @nycdotnet

[blakeembrey]

I'd prefer the term tsconfig.

Fair enough, you still point to a tsconfig.json file right? I'd love to have some more information on your project, it could affect a lot of ideas I've been thinking about.E.g. Moving tsd.json into tsconfig.json. As for using project, I use it for parity with tsc, editors and other tools which use the assumption (currently, I see tsconfig.json as I do package.json, in a sense).

[basarat]

As for using project, I use it for parity with tsc, editors and other tools which use the assumption

Yeah, I thought that too (see comment TypeStrong/grunt-ts#202 (comment)), but it definitely overloads the term if used in the ecosystem of other tools.

I'd be okay for current tools keeping project while new things go tsconfig, I'm not heavily biased.

I'd love to have some more information on your project, it could affect a lot of ideas I've been thinking about

Some hand waving here : https://github.com/basarat/tsb/tree/master and more why https://github.com/basarat/tsb/blob/master/docs/contributing/why.md ... I'll make it public (switch branches ... move to org) once there is more concrete stuff

[jbrantly]

you still point to a tsconfig.json file right?

I think this point is really important to make sure we're even naming the same thing.

• ts-loader - configFileName actually only takes a filename (and not a path). It uses the normal tsc lookup behavior to find the config file but just looking for a different file name.
• node-ts - project takes a directory path (no filename) and looks for a file called tsconfig.json there
• grunt-ts - tsconfig takes either true which looks for a file called tsconfig.json (in the current directory only?) or a full path (including filename) to a config file. Also allows a hash for other config-related options

I think it makes sense to first figure out which way, if any, we would want to standardize on before we can name it.

(btw, I gathered the above information in like 3 minutes so correct me if I'm wrong)

[jbrantly]

FWIW, the reason I went with the filename only approach in ts-loader is because I was trying to keep close to tsc behavior (look in current directory and all parent directories) but still allow people to specify different configs (like production.tsconfig.json).

[blakeembrey]

@jbrantly Sounds correct to me. I thought with the same idea, but ended up changing to using the same behaviour as tsc. Have you seen anyone using that sort of behaviour?

[nycdotnet]

Grunt-ts 5 uses tsconfig as the parameter name, as Bas said. We allow tsconfig to contain a file name or a folder name or true. If it's true we use the folder of the Gruntfile.

Grunt-ts is greedy, though. We actually parse the tsconfig.json ourselves as we do things like updating the files element. We then pass the tsconfig settings as switches. We also support a tsconfig passThrough feature where grunt-ts will just pass the project flag to tsc and do no further work. This is intended to support future or custom versions of tsc.

I am willing to consolidate tsconfig parsers as I agree there is no reason to have four or so floating around. The one in grunt-ts has fair test coverage and uses promises.

[blakeembrey]

@nycdotnet Cool to hear. I've just been using https://github.com/TypeStrong/tsconfig for parsing the config file (it also does the resolving from a directory look up and populating files with support for excludes and filesGlob). Then I've been merging passed in options and using ts.parseConfigFile to parse the object into something the language services uses - I found I haven't need much on top of that (Reference: https://github.com/TypeStrong/ts-node/blob/master/src/ts-node.ts#L38-L57).

If we're using the config filename option, I personally prefer the explicitness of configFile, tsconfig feels like I should be able to pass an object in myself to merge options.

[jbrantly]

Possibly related: microsoft/TypeScript#4883

Not merged (don't know if it will be merged) but I subscribed and if merged would certainly make sense to support supplying full paths for tsc equivalence.

[wyqydsyq]

I think transpileOnly should be implemented as a standard option for tsc, as mentioned previously, it's already used by ts-loader for activating a transpile-only mode, and could be leveraged by ts-node instead of their --fast option for activating a transpile-only mode, it also looks like the new Parcel bundler may have a use for this to enable fast transpilation for e.g. HMR while still providing type checking etc. by running tsc --transpileOnly and tsc --noEmit in seperate threads. That would be at least 3 different projects rolling their own implementation of what should really be a standard option.