Skip to content

Allow javascript (or typescript) config file #30400

Not planned
@alexmiddeleer

Description

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

Activity

j-oliveras

j-oliveras commented on Mar 14, 2019

@j-oliveras
Contributor

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

alexmiddeleer commented on Mar 14, 2019

@alexmiddeleer
Author

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.

added
SuggestionAn idea for TypeScript
Too ComplexAn issue which adding support for may be too complex for the value it adds
on Mar 15, 2019
paxperscientiam

paxperscientiam commented on Sep 29, 2019

@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

alexmiddeleer commented on Sep 29, 2019

@alexmiddeleer
Author

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

RyanCavanaugh commented on Sep 29, 2019

@RyanCavanaugh
Member

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

dradetsky commented on Aug 12, 2020

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

16 remaining items

qhantom

qhantom commented on Jan 22, 2023

@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

AndreiSoroka commented on Jan 22, 2023

@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

CEbbinghaus commented on Jan 23, 2023

@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

ValentinGurkov commented on Jun 9, 2023

@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

Tofandel commented on Jun 20, 2023

@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

typescript-bot commented on Jun 23, 2023

@typescript-bot
Collaborator

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

kf6kjg

kf6kjg commented on Jun 23, 2023

@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

Schweinepriester commented on Jun 23, 2023

@Schweinepriester

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

o-alexandrov

o-alexandrov commented on Jun 28, 2023

@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

cmcnicholas commented on Aug 18, 2023

@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

silverwind commented on Apr 25, 2024

@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

eXory2024 commented on Oct 7, 2024

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

kerryj89

kerryj89 commented on Dec 11, 2024

@kerryj89

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    SuggestionAn idea for TypeScriptToo ComplexAn issue which adding support for may be too complex for the value it adds

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @silverwind@s0ber@simonpai@dradetsky@kf6kjg

      Issue actions

        Allow javascript (or typescript) config file · Issue #30400 · microsoft/TypeScript