Typescript: Allow tsconfig to be a module, not only json

Created on 27 Jun 2018  路  20Comments  路  Source: microsoft/TypeScript

Search Terms

  • tsconfig js
  • tsconfig as module
  • tsconfig javasctipt

I have found a related question here: https://github.com/Microsoft/TypeScript/issues/9876#issuecomment-242383719. But that was not anyhow replied or addressed. So I have opened this issue.

Suggestion

Allow tsconfig file to be an executable module, not only static JSON

Use Cases

  1. When I have a non-trivial project structure and I want to use path.join(__dirname, 'path/to/file') to generate dynamic paths
  2. I have multiple projects and I would like to share the common configuration, but also I need to have a custom merging logic extends property doesn't work. Same also was asked there: https://github.com/Microsoft/TypeScript/issues/9876#issuecomment-242383719
  3. I have configuration for other tools, (webpack, for example), and I would like to share some constants between two tools

Also there is similar features in other tools:

Examples

tsconfig.js

const path = require('path');
const {rootDir, commonExcludes} = require('./constants');

module.exports = {
  "exclude": commonExcludes,
  "files": [
    path.join(rootDir, 'path/to/file')
  ]
}

Checklist

My suggestion meets these guidelines:

  • [x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
  • [x] This wouldn't change the runtime behavior of existing JavaScript code
  • [x] This could be implemented without emitting different JS based on the types of the expressions
  • [x] This isn't a runtime feature (e.g. new expression-level syntax)
Working as Intended

Most helpful comment

This seems to be a missed opportunity for flexibility for typescript. All those tools should be able to execute a bit of JS and have it report the config much like every other build tool config in the JS ecosystem like webpack.config.js, jest.config.js, gulp (gulpfile.js), babel (https://new.babeljs.io/docs/en/next/babelconfigjs.html). It seems like getting the config from a module is one require away.

All 20 comments

As a hacky workaround now I can generate tsconfig.json in runtime:

const config = {/*dynamically generated config*/};
require('fs').writeFileSync('tsconfig.json', JSON.stringify(config));

This works for compilation, but doesn't work for editors, because they do not see actual file.

The config file is meant to be statically understood by different tools, some of them have no capability nor need to execute JavaScript. for more dynamic modifications we recommend using a build tool e.g. gulp/jake/grunt/broccoli/etc.., or directly using the compiler API.

Got that, will have to stick with my workaround.

At least there is an issue now, that someone can upvote. Thank you for taking your time!

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@mhegazy Do you have examples of such tools that need to statically analyze tsconfig.json?

I too am running into this problem, as I want to share my configuration across projects. This sort of stuff becomes easier when we get dynamic abilities.

If I'm not using those such tools that statically analyze tsconfig, then why can't I choose to use a JS module instead? I don't care if some tool won't be able to statically analyze my tsconfig... because I'm not using those tools...

When trying to share tsconfig (and other build scripts and configs) across projects, this gets in the way in some cases if I can't use process.cwd() or similar to set certain paths.

npm link workflows may end up placing tsconfig at different levels inside of node_modules, not just at the top level, so we can not write stuff like ../src/**/* and expect it to work all the time.

Do you have examples of such tools that need to statically analyze tsconfig.json?

TypeScript itself, Visual Studio, Visual Studio Code, etc...

Do you have examples of such tools that need to statically analyze tsconfig.json?

TypeScript _itself_, Visual Studio, Visual Studio Code, etc...

Does these tools analyze js config files like webpack.config.js or babel.config.js?
WebStorm does (without passing params by default, but still)

This seems to be a missed opportunity for flexibility for typescript. All those tools should be able to execute a bit of JS and have it report the config much like every other build tool config in the JS ecosystem like webpack.config.js, jest.config.js, gulp (gulpfile.js), babel (https://new.babeljs.io/docs/en/next/babelconfigjs.html). It seems like getting the config from a module is one require away.

For anybody still interested in this feature: https://www.npmjs.com/package/tsconfig.js

Personally I'd like to see them use the node-interpret package to determine how to load the configuration file. I'd LOVE to be able to create a dynamic configuration file IN typescript by creating a tsconfig.ts (like webpack does webpack.config.js) and node-ts runs the module

@dl748
Sounds interesting. If you'd like to see that in tsconfig.js, please open an issue there: https://github.com/rasenplanscher/tsconfig.js/issues/new

I wanted to look into this just now. A quick search the mentioned node-interpret package yielded https://github.com/gulpjs/interpret, which doesn't seem right. Please include a useful reference if you open an issue.

@rasenplanscher
That is correct, it is apart of the gulpjs project but it doesn't require gulp.

See https://webpack.js.org/configuration/configuration-languages/

Source for use

https://github.com/webpack/webpack-cli/blob/next/packages/webpack-cli/lib/groups/ConfigGroup.js

tsconfig.js v2 is now on npm and includes interpret-based transpilation 馃コ馃帀

@dl748
Thanks for the info!

tsconfig.js v2 is now on npm and includes interpret-based transpilation 馃コ馃帀

@dl748
Thanks for the info!

You should add to the documentation though, that if loading other extensions like coffee or typescript, you need to make sure the required loader (e.g. coffeescript for .coffee and ts-node for .ts) is installed

Good point, done 馃憤

I really see little harm in allowing dynamic configs and letting the editor decide which to use. No one is saying remove tsconfig.json support, so there's no breaking changes. ESLint is also an editor-compatible tool that can be configured dynamically, so the argument that editors wouldn't be able to understand TS suddenly is pretty weak.

Right now, TS is literally the only tool I cannot configure dynamically, and it's quite frustrating, resorting to me having to use hacky methods like generating the file dynamically, which doesn't work well with editors.

@ryall
Have you tried tsconfig.js? If that produces issues with your editor, please open an issue there.

@rasenplanscher I have my own similar implementation, however that's not really the point. I think dynamic config should be part of the core architecture rather than an external library.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

wmaurer picture wmaurer  路  3Comments

CyrusNajmabadi picture CyrusNajmabadi  路  3Comments

DanielRosenwasser picture DanielRosenwasser  路  3Comments

jbondc picture jbondc  路  3Comments

MartynasZilinskas picture MartynasZilinskas  路  3Comments