Allow javascript (or typescript) config file

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.

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. */
  }
}

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.

Alex Middeleer (@alexmiddeleer)

Alex Middeleer (@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.

Microsoft GitHub User (@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

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.

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.

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@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).

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?

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.

Ryan Cavanaugh (@RyanCavanaugh)

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

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

This would be nice to have.

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

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh), can you give any solution or comment for us?

Gerrit (@qhantom)

Gerrit (@qhantom) Simon Pai (@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

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.

CEbbinghaus (@CEbbinghaus)

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 (@CEbbinghaus) but I'd prefer to not include this overhead.

Please consider allowing the config as a javascript file.

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?

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

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

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh): TypeScript Bot (@typescript-bot) is misbehaving, please reopen this issue.

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

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.

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

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.

I don't see a good argument against this. Simple json configs are nice (I'd prefer it if it works for my use case), but your simple configs doesn't allow for merging which is a pain in a world where monorepos are only gaining popularity. Why not let users with more complex setups handle these ambiguities (which can often harbor on opinions)? Then you'll make everyone happy. You can still steer towards the simple json config in your docs, but if you have no plan on making tsconfig.json easier to use with monorepos (which might only make them more convoluted), then I hope you reconsider allowing js for more advanced use cases. Just my 2c - thanks!

now in 2026 ts.config.ts is a good standar

I'd ask for extending tsconfig's JSONC with some extra stuff, like const variables and restricted methods (map, flatMap, filter, toSorted, and friends).

Navigation Menu

Repository navigation

Allow javascript (or typescript) config file #30400

Suggestion

Use Cases

Examples

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow javascript (or typescript) config file #30400

Description

Suggestion

Use Cases

Examples

Activity

j-oliveras commented on Mar 14, 2019

alexmiddeleer commented on Mar 14, 2019

paxperscientiam commented on Sep 29, 2019

alexmiddeleer commented on Sep 29, 2019

RyanCavanaugh commented on Sep 29, 2019

dradetsky commented on Aug 12, 2020

CEbbinghaus commented on Aug 22, 2021

s0ber commented on Feb 19, 2022

AndreiSoroka commented on Mar 18, 2022

paulshryock commented on Apr 1, 2022

xuyanzhuqing commented on Jun 29, 2022

AndreiSoroka commented on Jun 29, 2022

9 remaining items

AndreiSoroka commented on Jan 22, 2023

CEbbinghaus commented on Jan 23, 2023

ValentinGurkov commented on Jun 9, 2023

Tofandel commented on Jun 20, 2023

typescript-bot commented on Jun 23, 2023

kf6kjg commented on Jun 23, 2023

Schweinepriester commented on Jun 23, 2023

o-alexandrov commented on Jun 28, 2023

cmcnicholas commented on Aug 18, 2023

silverwind commented on Apr 25, 2024

eXory2024 commented on Oct 7, 2024

kerryj89 commented on Dec 11, 2024

DanhezCode commented on Aug 19, 2026

irfanstract commented on Aug 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions