`next dev` rewrites tsconfig.json

Bug report

Describe the bug

When I run next dev and some of the “required” Next.js options are missing (even non-critical ones like forceConsistentCasingInFileNames), my tsconfig.json is completely rewritten – my comments are deleted and the file is re-formatted.

To Reproduce

1. Start next dev
2. In tsconfig.json, remove forceConsistentCasingInFileNames and add some comment.
3. Start next dev again
4. Observe that your comment is deleted

Expected behavior

My tsconfig.json is my tsconfig.json 😄.

System information

• OS: macOS
• Version of Next.js: 9.0.2

Additional context

This is from the “TypeScript support is too eager in v9” bucket, IMO. Some more issues I’d regard in that category are e.g. #7687 or #8065 (though they are about different things).

[borekb]

isolatedModules is certainly debatable – for example, we’d like to make a tradeoff between performance and safety in our case. (Next+TS can run perfectly fine without this option.) It’s hard for a tool to predict all the possible circumstances and be 100% right all the time.

I just don’t think that Next.js should be writing into my source files, especially as a by-product of something as innocent-looking as next dev. I’d prefer any of these:

• Next.js could encode the default tsconfig in some internal way, similarly to how webpack config is hidden from me
• next dev could validate that the configuration is correct and warn me / refuse to start if some critical config is not met
• There could be a manual command like next init-tsconfig

Maybe there are some other options as well. I understand the good intent though and appreciate your effort around this!

[borekb]

It’s indeed the same issue as #8034, sorry for not noticing it earlier.

It’s OK for Next.js to generate new tsconfig.json when there is none (it’s very useful, actually) but overwriting existing files, possibly losing user’s work, is something that no tool should do, ever, IMO.

It’s also debatable whether Next.js “needs” some of the things it says so, for example, I don’t think compilerOptions.isolatedModules is required for Babel and there are serious performance implications of having this turned on, for example, https://github.com/microsoft/TypeScript/issues/32294.

What I’m trying to say: in the end, tsconfig should be user’s responsibility. It’s fine if Next.js makes reasonable suggestions or does some changes automatically in some cases, but it should be careful and conservative, IMO.