I have multiple projects with multiple tsconfig.json files (and other config files) and my goals is to use the same in each projects.
To achieve that I decided to create a npm package config, with a standard tsconfig.json file (and other .json config files).
my previous typescript's command in order to build my project were tsc -p tsconfig.json --incremental and I tried to change it to tsc -p tsconfig.js --incremental with a tsconfig.js file looking like:
module.exports = {
...require('./node_modules/@myOrg/myPackage/tsconfig.json')
};
Using spread where I could override some properties if needed.
My idea seems to be legit but it doesn't works, it doesn't compile using tsc with this config file because it omit each tsconfig.json's properties (such as esModuleInterop, downlevelIteration, es2015, etc...) which are obviously in the package's tsconfig.json.
How can I achieve my goal ? may this technique works for every other .json config file except tsconfig.json because some of it's flags are required to make it possible
An executable config module is explicitly not supported:
We are not accepting PRs to turn config into an executable thing. This opens up an enormous can of worms (is it safe to run this? what dependencies does the config file have? what does the config file assume about its environment?) that we'd prefer remain closed.
GitHub: Allow javascript (or typescript) config file <Suggestion> (#30400)
You haven't said why you are centralizing your tsconfig. If it's just for convenience, then you could just use the extends option to inherit configuration options from another tsconfig file.
Note that "All relative paths found in the configuration file will be resolved relative to the configuration file they originated in." So, following this approach would likely prevent you from inheriting all properties. You'd probably need to supply at least a few options in your local config file (such as files).
If you really want to copy your tsconfig wholesale (including relative file paths), then you could use a build tool (like gulp) to copy the tsconfig.json from a well-known location to your project root before running tsc. I'm sure you can imagine some of the problems this would introduce, including requiring a developer to perform extra CLI steps before loading the project in an editor like VS Code.
A base config can be very useful for standardizing your builds, but there's a risk you will cause more problems than you solve over the long-term. It's important to strike a balance. Inheriting too much from an outside source will stiffen your project, making it difficult to adapt to environmental changes or new technologies. You may find yourself needing to adjust the base configuration for the sake of one project, but those adjustments may be incompatible with another. Or your may find yourself constantly overriding the same properties from your base configuration because your preferences changed but older projects still depend on those old options. You might get around this by versioning or tagging, but then what have you gained? You still have more than one config, they're just harder to find and use. There are good reasons to keep your project configuration with your project.
Inheriting from a common config isn't necessarily all bad, but over-dependence on inheritance will, in my opinion, cause long-term issues that are harder to address than just copying your tsconfig from a template.