Allow tsconfig to be a module, not only json

[just-boris]

Search Terms

• tsconfig js
• tsconfig as module
• tsconfig javasctipt

I have found a related question here: #9876 (comment). 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: Configuration Inheritance #9876 (comment)
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:

• babel.config.js
• .eslintrc.js
• There is also cosmicconfig package, that provides such functionality.

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:

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

[just-boris]

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.

[mhegazy]

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.

[just-boris]

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!

[typescript-bot]

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

[trusktr]

@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.

[trusktr]

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...

[trusktr]

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.

[RyanCavanaugh]

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

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

[DarthVitalus]

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)

[kenotron]

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.

[c-vetter]

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

[dl748]

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

[c-vetter]

@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.

[dl748]

@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

[c-vetter]

tsconfig.js v2 is now on npm and includes interpret-based transpilation 🥳🎉

@dl748
Thanks for the info!

[dl748]

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

[c-vetter]

Good point, done 👍

[ryall]

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.

[c-vetter]

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

[ryall]

@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.

[lionel-bijaoui]

Since it has been almost 4 year since this issue was brought up, can we reopen the issue ?
If ESLint is able to do it, I don't see why Typescript would be unable.

When faced with more complex projects, the ability to define compilerOptions.paths dynamically is needed.

Can we please at least give it a shot?
Thanks

[AprilArcus]

In my monorepo, I would like to be able to dynamically derive project references from the namespaced dependencies enumerated in my package.json, so that package.json can be the single store of truth for each workspace's dependency graph.

[TowhidKashem]

My eslintrc.js file is full of comments RE why each rule was chosen or what it does. It would be great to be able to do the same in a tsconfig.js file as well. For things like obscure config rules it really helps to be able to leave comments!