Not planned
Description
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 commentedon Mar 14, 2019
Did you know that you can add comments to
tsconfig.json
?Try it with
tsc --init
, that produces a heavily commentedtsconfig.json
file. Here a example generated with typescript 3.3.3333:alexmiddeleer commentedon Mar 14, 2019
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 commentedon Sep 29, 2019
@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
, ortsconfig.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 commentedon Sep 29, 2019
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 commentedon Sep 29, 2019
This format is known as JSON5
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.
extends
path using node_modules resolution logic #18865dradetsky commentedon Aug 12, 2020
@RyanCavanaugh you said
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 commentedon Jan 22, 2023
Thanks @simonpai that helped a lot!
AndreiSoroka commentedon Jan 22, 2023
@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 commentedon Jan 23, 2023
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 commentedon Jun 9, 2023
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 commentedon Jun 20, 2023
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 malwaretsconfig.js
file to run code when runningtsc
, first you are running a build command already which has so many more options to execute code than thetsconfig
so you should already never do that in an untrusted project, it's even possible on runningnpm install
(post-install
hook) on the project already which you need to do to get typescript so it's really a non issueThe 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 commentedon Jun 23, 2023
This issue has been marked as "Too Complex" and has seen no recent activity. It has been automatically closed for house-keeping purposes.
kf6kjg commentedon Jun 23, 2023
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 commentedon Jun 23, 2023
@RyanCavanaugh: @typescript-bot is misbehaving, please reopen this issue.
o-alexandrov commentedon Jun 28, 2023
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.
tsconfig
isjson5
(json w/ comments), the import involves an extrajson5
librarycmcnicholas commentedon Aug 18, 2023
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 usingextends
which don't satisfy all the needs of how merging should happen.tsconfig.json
is a thorn in our side for maintenance.silverwind commentedon Apr 25, 2024
#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 commentedon Oct 7, 2024
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 commentedon Dec 11, 2024
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!