`next dev` rewrites tsconfig.json

[borekb]

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

[Janpot]

Also #8034

[Timer]

If you don't want forceConsistentCasingInFileNames to be true, set it to false instead of deleting the field.

We can look into retaining comments.

[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, microsoft/TypeScript#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.

[Timer]

@borekb Whether or not compilerOptions.isolatedModules is needed is not debatable -- it is an invariant.

Without this option, TypeScript features that are not supported by Babel will break in unexpected / indeterminate ways and cause countless hours of debugging.

I agree that the config overwrite should never be "destructive", and we'll work on fixing this.

[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!

[Timer]

I've scheduled this for work in 9.0.7, here's what we'll do:

1. Next.js will not erase comments from your tsconfig.json.
2. Next.js will not override options you have set without prompting you first. You can answer "No" and edit them manually.
3. Next.js will still create a default (but overridable) tsconfig.json for the user if not present.

[majelbstoat]

That's great, thank you 🙏🏼 Can we please also support its (and next-env.dts') location in a configurable place?

[webhacking]

9.0.7-canary.4 works fine.