Allow javascript (or typescript) config file

[alexmiddeleer]

Suggestion

I suggest allowing a tsconfig.js or tsconfig.ts as an optional alternative to tsconfig.json.

Use Cases

What do you want to use this for? Primarily to add comments to the tsconfig file.
What shortcomings exist with current approaches? JSON does not allow comments. You can't even hack in comments by adding fake fields like "_explanationOfTypeRoots", as the build complains about unknown compiler options and stops.

Examples

Many tools and frameworks allow javascript config files. Jest, for example. jest --init produces a heavily commented config file, which is very useful for beginners.

[j-oliveras]

What do you want to use this for? Primarily to add comments to the tsconfig file.

Did you know that you can add comments to tsconfig.json?

Try it with tsc --init, that produces a heavily commented tsconfig.json file. Here a example generated with typescript 3.3.3333:

{
  "compilerOptions": {
    /* Basic Options */
    "target": "es5",                          /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017','ES2018' or 'ESNEXT'. */
    "module": "commonjs",                     /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', or 'ESNext'. */
    // "lib": [],                             /* Specify library files to be included in the compilation. */
    // "allowJs": true,                       /* Allow javascript files to be compiled. */
    // "checkJs": true,                       /* Report errors in .js files. */
    // "jsx": "preserve",                     /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
    // "declaration": true,                   /* Generates corresponding '.d.ts' file. */
    // "declarationMap": true,                /* Generates a sourcemap for each corresponding '.d.ts' file. */
    // "sourceMap": true,                     /* Generates corresponding '.map' file. */
    // "outFile": "./",                       /* Concatenate and emit output to single file. */
    // "outDir": "./",                        /* Redirect output structure to the directory. */
    // "rootDir": "./",                       /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
    // "composite": true,                     /* Enable project compilation */
    // "removeComments": true,                /* Do not emit comments to output. */
    // "noEmit": true,                        /* Do not emit outputs. */
    // "importHelpers": true,                 /* Import emit helpers from 'tslib'. */
    // "downlevelIteration": true,            /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */
    // "isolatedModules": true,               /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */

    /* Strict Type-Checking Options */
    "strict": true,                           /* Enable all strict type-checking options. */
    // "noImplicitAny": true,                 /* Raise error on expressions and declarations with an implied 'any' type. */
    // "strictNullChecks": true,              /* Enable strict null checks. */
    // "strictFunctionTypes": true,           /* Enable strict checking of function types. */
    // "strictBindCallApply": true,           /* Enable strict 'bind', 'call', and 'apply' methods on functions. */
    // "strictPropertyInitialization": true,  /* Enable strict checking of property initialization in classes. */
    // "noImplicitThis": true,                /* Raise error on 'this' expressions with an implied 'any' type. */
    // "alwaysStrict": true,                  /* Parse in strict mode and emit "use strict" for each source file. */

    /* Additional Checks */
    // "noUnusedLocals": true,                /* Report errors on unused locals. */
    // "noUnusedParameters": true,            /* Report errors on unused parameters. */
    // "noImplicitReturns": true,             /* Report error when not all code paths in function return a value. */
    // "noFallthroughCasesInSwitch": true,    /* Report errors for fallthrough cases in switch statement. */

    /* Module Resolution Options */
    // "moduleResolution": "node",            /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
    // "baseUrl": "./",                       /* Base directory to resolve non-absolute module names. */
    // "paths": {},                           /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
    // "rootDirs": [],                        /* List of root folders whose combined content represents the structure of the project at runtime. */
    // "typeRoots": [],                       /* List of folders to include type definitions from. */
    // "types": [],                           /* Type declaration files to be included in compilation. */
    // "allowSyntheticDefaultImports": true,  /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */
    "esModuleInterop": true                   /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */
    // "preserveSymlinks": true,              /* Do not resolve the real path of symlinks. */

    /* Source Map Options */
    // "sourceRoot": "",                      /* Specify the location where debugger should locate TypeScript files instead of source locations. */
    // "mapRoot": "",                         /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSourceMap": true,               /* Emit a single file with source maps instead of having a separate file. */
    // "inlineSources": true,                 /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */

    /* Experimental Options */
    // "experimentalDecorators": true,        /* Enables experimental support for ES7 decorators. */
    // "emitDecoratorMetadata": true,         /* Enables experimental support for emitting type metadata for decorators. */
  }
}

[alexmiddeleer]

Oh, nice! I was under the impression that comments were not allowed in JSON, but it makes sense that someone would write a parser that allows them. Thank you for your response, I am closing the issue because I no longer think this feature is necessary.

[paxperscientiam]

@alexmiddeleer No, YOU are right -- JavaScript style comments aren't allowed in JSON; tsc --init produces an invalid JSON file. The parser, of course, is permissive.

@msftgits should consider an alternative format for autogenerated config files. This could be solved easily by allowing tsconfig.yaml, tsconfig.js, or tsconfig.ts while continuing to support tsconfig.json in perpetuity.

EDIT: I'm guessing the parser just interprets the content of tsconfig.json as JavaScript

[alexmiddeleer]

I agree that more config options would be ideal. But I’m guessing the core team needs to focus on higher priority items. Maybe this would be a good first contribution for someone new.

[RyanCavanaugh]

This format is known as JSON5

EDIT: I'm guessing the parser just interprets the content of tsconfig.json as JavaScript

JSON is a different top-level production because the initial { indicates an object, not a statement block.

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.

[dradetsky]

@RyanCavanaugh you said

We are not accepting PRs to turn config into an executable thing.

Would you accept a PR to support only yaml? Or for that matter, other non-executable formats (e.g. toml, ini, etc, but I'm only interested in yaml).

[CEbbinghaus]

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.

This makes little sense to me when so many other JS libraries support them.

#39441 names a few but there are plenty more that all allow this behaviour. If every one of them had a discussion on the same security concerns, then wouldn't looking through their discussions yield the information needed to implement it in a safe and responsible fashion?

[s0ber]

One could always generate the config dynamically. It just makes it harder to get the job done when js execution is forbidden. So yeah, it’d be REALLY nice to have this feature.

But I understand there could be security implications in IDEs environments.

[AndreiSoroka]

What needs to be done to convince developers? For them to add support tsconfig.js? @RyanCavanaugh

P.s. I have common configs between my micro-frontends. tsconfig.JSON - it is the uncomfortable restriction

[paulshryock]

This would be nice to have.

[xuyanzhuqing]

Oh, nice! I was under the impression that comments were not allowed in JSON, but it makes sense that someone would write a parser that allows them. Thank you for your response, I am closing the issue because I no longer think this feature is necessary.

I think at lease the developer could have the chooise, not just be accept the " I no longer think this feature is necessary" , as far as I can see, I am trying to use git-submodule for my project, it means at lease I have tow or more projects to be located in one root folder, I just want to dynamicly modifiy the "compilerOptions.path", but it is impossible, it makes me feel bad

[AndreiSoroka]

@RyanCavanaugh, can you give any solution or comment for us?

[AndreiSoroka]

@RyanCavanaugh please, don't ignore us

[CEbbinghaus]

Should @alexmiddeleer reopen the issue and we focus this on the JS config to dynamically edit properties within the tsconfig at compile time, or do we leave this closed as it was specifically about comments within the JSON and open a new issue to focus on the dynamic aspect?

[dandonahoe]

Please leave an explanation about why the issue was closed. If this can't be achieved for some reason, at least explain so we can drop it.

This is a big thorn in many projects.

[alexmiddeleer]

I am reopening since this has so much interest. I closed it initially out of respect for the maintainer’s statements that they didn’t want to support it.

[alexmiddeleer]

Though I have some misgivings about issue resurrection and think a fresh issue might be better to make the history less muddy. This one’s initial use case turned out to be solved already.

[CEbbinghaus]

So in one of the other issues #30751, there is a reference to an npm package that implements some of this behavior already: tsconfig.js. As good as it is that there exists an alternative, it essentially functions as a generator that you feed a js file into and a JSON file comes out.

In the readme for that project is also mentioned an excerpt from the Design Meeting Notes, 9/28/2018

• What about tsconfig.js?
  • Nooooooooooooooooooooooooooooo

Which I feel sums up the attitude towards this suggestion. With very vague hard waving we are assured that it would be too complicated or too big of a security concern.

If any concrete concerns exist then those can be addressed, If it's just feeling uncomfortable with the idea of a js config, then the existence of webpack.config.js, vite.config.js, .eslintrc.js and many other config files should help reassure that this is a common and safe practice. I mean even the Gulpfile.js in this very project shows that having your configuration as an interpreted js file is sometimes necessary.

Most other build tools use executable configurations since they allow for more reuse and flexibility, so I am having a hard time justifying how TypeScript is different from any of the other build tools that all support js configurations.

Edit: The Gulpfile was renamed to Gulpfile.mjs and subsequently to Herebyfile.mjs in f45cc45. The Above link has been updated to point to the correct file, However I kept the Gulpfile name as it is more recognizable as to its purpose

[simonpai]

Somehow the npm package mentioned above didn't work for me. I came up with a stupid yet simple solution:

1. Write a node script to output a tsconfig.json file by evaluating your tsconfig.js.
2. Add the above step into your build process.
3. Optionally add tsconfig.json to your .gitignore.

See the gist for code examples. I hope this helps.

[qhantom]

Somehow the npm package mentioned above didn't work for me. I came up with a stupid yet simple solution:

1. Write a node script to output a tsconfig.json file by evaluating your tsconfig.js.
2. Add the above step into your build process.
3. Optionally add tsconfig.json to your .gitignore.

See the gist for code examples. I hope this helps.

Thanks @simonpai that helped a lot!

[AndreiSoroka]

@qhantom @simonpai but anyway it is a workaround 😞

I don't understand. How many people should highlight the problem? No any comment from Microsoft developers, they just ignore the current topic

[CEbbinghaus]

for anyone wondering the best way to ensure that these topics get seen & taken seriously is to upvote the original comment that started the issue. Doing so bumps the issue further up the list of things for the TS team to tackle. So anyone wanting to see this added should upvote & encourage others that want the same functionality to do the same.

[ValentinGurkov]

I also want to share our use case where this would have been most helpful.
We have a monorepo with microservices and every microservice will be built in a docker container, the container will only have access to what is inside the microservice folder.

Our solutions are to copy the same tsconfig.json every or have the docker container run at the root level, which also has its' downsides.

With jest and eslint this was easy enough to solve since the javascript config file can be a common package and can be imported into the config files for the microservice, eliminating the need to copy the same config everywhere.

With the tsconfig we can't since it allows only JSON. Unless we create some process that will convert our custom JS config to JSON, like in the comment from @CEbbinghaus but I'd prefer to not include this overhead.

Please consider allowing the config as a javascript file.

[Tofandel]

Seeing that babel, eslint, tailwind, vite and so many more libs allow .js for their config files as well as .json, it would make sense to allow it as well in typescript, because though it theoretically allows a project with a malware tsconfig.js file to run code when running tsc , first you are running a build command already which has so many more options to execute code than the tsconfig so you should already never do that in an untrusted project, it's even possible on running npm install (post-install hook) on the project already which you need to do to get typescript so it's really a non issue

The benefit of a js file is to allow for much more flexible configuration, comments is just one small added benefit

Mainly it would allow the config to contain functions, which could be very useful for ts plugins, because functions are not json encodable, it would also allow export and import, as well as a more flexible composable approach than what currently exists

I don't know if allowing a .ts file would be a good idea though because it's a chicken and the egg problem, how do you run this file without typescript knowing it's config?

[typescript-bot]

This issue has been marked as "Too Complex" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[kf6kjg]

How does a bot make a judgment call? Especially for a feature that is not especially complex and has indeed had recent activity? I say reopen the ticket, there's design work to do by humans.

[Edit: In case my rhetorical questions are misunderstood: I assume a human was behind the bot, either by direct action behind the curtain or by programming the heuristic. In the former case, please step up and join the conversation. In the latter, the bot needs some tuning.]

[Schweinepriester]

@RyanCavanaugh: @typescript-bot is misbehaving, please reopen this issue.

[o-alexandrov]

JavaScript tsconfig file is useful more than ever, due to the relatively new change in the behavior of ESLint + TypeScript parser.
To avoid a bug related to ESLint & tsconfig included files, a developer might want to reuse included & excluded directives, instead of hardcoding them.

• one workaround is to import a tsconfig.json into ESLint config and reuse the directives, but since tsconfig is json5 (json w/ comments), the import involves an extra json5 library

[cmcnicholas]

This really needs to be re-assessed, we have large monorepo's, a hundred or so tsconfig.json with repeated content due to merging strategies when using extends which don't satisfy all the needs of how merging should happen. tsconfig.json is a thorn in our side for maintenance.

[silverwind]

#57486 highlights the need for this. It tries to invent complex syntax for merging/extending when it could just be done by the user in a code config file.

[eXory2024]

Please make this happen, other tools are using dynamic configs too so it can't be that big of a problem.

Also, if you are going to use a dynamic config it's your responsibility to make that code not do stupid things.