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.
Allow tsconfig
file to be an executable module, not only static JSON
path.join(__dirname, 'path/to/file')
to generate dynamic pathsextends
property doesn't work. Same also was asked there: https://github.com/Microsoft/TypeScript/issues/9876#issuecomment-242383719Also there is similar features in other tools:
tsconfig.js
const path = require('path');
const {rootDir, commonExcludes} = require('./constants');
module.exports = {
"exclude": commonExcludes,
"files": [
path.join(rootDir, 'path/to/file')
]
}
My suggestion meets these guidelines:
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 includesinterpret
-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.
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.