next dev rewrites tsconfig.json when it shouldn't

[jakubmazanec]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

    Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Enterprise
    Binaries:
      Node: 16.15.1
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.2.6-canary.4
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

Describe the Bug

Next.js rewrites tsconfig.json even when it doesn't need to. In the reproduction repo it's adding "exclude": ["node_modules"], even though node_modules directory is covered by the default of exclude (see https://www.typescriptlang.org/tsconfig#exclude). There are other similar situations when Next.js thinks it's smarter than me and changes tsconfig.json, but they are not included in the reproduction repo because it is not relevant to the proposed solution.

Also, when making those edits, Next.js doesn't respect Prettier config.

This is tsconfig.json from the reproduction repo:

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "incremental": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve"
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"]
}

This is tsconfig.json after following the steps to reproduce the bug:

{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "incremental": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve"
  },
  "include": [
    "next-env.d.ts",
    "**/*.ts",
    "**/*.tsx"
  ],
  "exclude": [
    "node_modules"
  ]
}

Expected Behavior

Next.js never touches tsconfig.json. It can print warnings, but I should be able to turn them off.

Link to reproduction

https://github.com/jakubmazanec/nextjs-tsconfig-bug

To Reproduce

1. Clone https://github.com/jakubmazanec/nextjs-tsconfig-bug
2. Run npm install
3. Run npm run dev
4. Observe changed tsconfig.json

[SukkaW]

@jakubmazanec

Currently, overwriting the tsconfig.json is the intended behavior.

Do you have any specific properties/configurations that do not want to be overwritten by Next.js?

[SukkaW]

Exactly, therefore Next.js shouldn't event touch tsconfig.json, just print warning if it isn't sure all necessary options have correct values.

Next.js will not overwrite your config every time you next build. It only checks your tsconfig.json, searches for invalid configurations that could break Next.js, and only perform a full overwrite after one is detected.

I will create a PR to include the composite detection though.

[jakubmazanec]

I will create a PR to include the composite detection though.

And does Next.js handle extends correctly? Common use case is having tsconfig.options.json in the root of a monorepo with shared compilerOptions settings from which the tsconfigs in app directories extend.

[akosradler]

Do you have any specific properties/configurations that do not want to be overwritten by Next.js?

Yeah, all of them. What makes you think its okay for Next to overwrite anything in MY tsconfig?
I have a project on Next 12, where even though I'm using TS5, I cannot set moduleResolution to bundler because Next rewrites my config.

[Santiago-j-s]

I would want for strictNullCheck to not be added if not already present on the tsconfig file

Context: We are refactoring a large legacy app that uses the pages router. We are gradually moving pages into the app router. To ensure strict TypeScript compliance for all new code, we use https://github.com/allegro/typescript-strict-plugin. Previously, the strict property was set to false.

The typescript-strict-plugin affects the strict property, not strictNullChecks.

When strictNullChecks is enabled, all files are examined for null and undefined, including those with the @ts-strict-ignore comment.

When strictNullChecks is disabled, no files are checked for null and undefined, even those without the @ts-strict-ignore comment.

[g-wozniak]

it rebuilds tsconfig files ("react" property) in all sibling projects outside the NextJS project, unrelated to it - how is that desirable? :)

[balazsorban44]

This sounds like a broader ask/feature request, rather than an addressable bug, but if you have a reproduction where any of the Next.js configured options is causing a bug in your application, please let us know.

[jakubmazanec]

What is actually buggy behavior is #37525 - if Next.js didn't forcibly rewrite tsconfig.json all the time, we could use moduleResolution: "node16".

[kostia1st]

In my case I already have strict: true in the base tsconfig, but next.js keeps adding "strictNullChecks": true to the project level tsconfig regardless.
Also it adds ".next/types/**/*.ts" to include, although I already have "**/*.ts" there. Why?

It does not break anything, but I don't get it - why clutter the config for no reason.

[kyldvs]

Yeah this is really annoying, next js keeps adding strictNullChecks even when I have it in the base .tsconfig. I should be able to turn off nextjs' ability to modify the tsconfig. I'm happy with all the options nextjs needs to setup, but if it can't recognize them being present in the base config I'm importing via "extends": "tsconfig/nextjs.json", then I should have an option to tell nextjs "trust me" and don't modify the tsconfig.

[vinnycodes]

Agree with @kyldvs on this.
There should be an option to tell nextjs "I've got this". Especially when there's already a tsconfig present and a present configuration.

[AriaMinaei]

In my case, next.js keeps adding "noEmit": true even though "composite": true, making typescript complain that composite projects shouldn't have noEmit set to true.

[jgalminas]

Exact same issue

[jblz]

+1 for respecting the prettier & / or eslint configs if the framework overwrites config files.

[dawi]

I spend hours to understand why nextjs modifies my tsconfigs in a multi workspace project, but had to give up.
It adds strictNullChecks true to one module, but not to another, although they a almost identically.

[Willem-Jaap]

Same, latest version of Turbo & Next.js, I use "extends": "tsconfig/nextjs.json", like described in the turbo docs.

[guillaumeduhan]

Hello guys,
How can we disable this? It makes even my VSCode to crash with my actual configuration of Intellisense.
Thanks for all your messages!

[power-f-GOD]

@timneutkens Please.🤲🏼

[GermanJablo]

Related issue: #19155

which is very annoying.

Please do not overwrite tsconfig, or at least let us opt out...

[Moe03]

+1 really annoying, there should be an option to stop that already now?

[david-morris]

I have a situation where I'm using NX and this stops me from being able to use both storybook and the app router. All this needs is to issue a warning and have an argument to auto-fix. Then we could have fixed it manually in the correct config (which you didn't find).

This is frustrating, undesirable behavior not connected with functionality. Please stop deciding for others what data files on their computers should contain.

[danielbruni]

Anyone found a workaround? Iam using NX and since this happens, i cant do a successful deploy with app dir. It changes my tsconfig on deployment :(

[danielbruni]

found a hacky solution for my apps/my-project/tsconfig.json with NX:

"include": [
    "**/*.ts",
    "**/*.tsx",
    "**/*.js",
    "**/*.jsx",
    "next-env.d.ts",
    "**/*.cjs",
    "**/*.mjs",
    "../../apps/my-project/.next/types/**/*.ts",
    "../../dist/apps/my-project/.next/types/**/*.ts"
  ],
  "exclude": [
    "node_modules",
    "jest.config.ts",
    "src/**/*.spec.ts",
    "src/**/*.test.ts",
    "../../apps/my-project/.next/types/**/*.ts",
    "../../dist/apps/my-project/.next/types/**/*.ts"
  ]

[Jared-Dahlke]

ughh. should have just stuck with Vite

[derek-primumco]

Hey @leerob and team! Why isn't this fixed yet? I specifically do not want a "lib" section in my tsconfig.json, but just running Next.js dev server results in the following entry added to tsconfig.json.

"lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ]

I'll quote https://www.typescriptlang.org/tsconfig#target:

Changing target also changes the default value of lib. You may “mix and match” target and lib settings as desired, but you could just set target for convenience.

[martinbiard]

In my opinion, it is pretty short-sighted to not have an option to turn this off. I understand and can appreciate tools that make it easy to get started, however when your configurations grow to be more complex, you need a way to regain total control over your configuration files.

My use case is, in a monorepo, all packages are structured in the same way. My frontend apps have the following tsconfig files:

/monorepo
  /apps
    /my-nextjs-app
      /src
        ...
      tsconfig.build.json
      tsconfig.cypress.json
      tsconfig.jest.json
      tsconfig.json (the overwritten one)
  tsconfig.json

The tsconfig file marked as being overwritten above contains the following:

{
    "$schema": "https://json.schemastore.org/tsconfig",
    "extends": "@lazr/tools/etc/shared/tsconfig/tsconfig.node.json",
    "compilerOptions": {
        "baseUrl": "."
    },
    "files": [],
    "references": [
        {
            "path": "./tsconfig.build.json"
        },
        {
            "path": "./tsconfig.cypress.json"
        },
        {
            "path": "./tsconfig.jest.json"
        },
        {
            "path": "./../../tsconfig.json"
        }
    ]
}

Having warnings during next build and making sure my base tsconfig.json (at root of monorepo) and my tsconfig.build.json have correct values was easy enough to do. Patching nextjs to make it stop overwriting my tsconfig.json was something I wish I didn't have to do. I use pnpm and have created a patch for it that I will attach if anyone else needs it.
[email protected]

[erayaydin]

The following suggested values were not only suggested but also recklessly added to your tsconfig.json file without bothering to ask for your opinion or consent.

[david-morris]

I think that the XZ fiasco shows the risks of losing our composure while discussing open-source software.

It behooves us to be friendly and fact-focused, even when maintainers have made choices which we feel affect us negatively or overstep boundaries.

As someone else who has issues with next rewriting tsconfig files, I would appreciate it if you posted more details about the problems this behavior causes in your project!

[erayaydin]

I want to clarify that my intention is not to undermine F/OSS projects in a negative side. I believe that a popular project developed with contributions from the community should also take actions that benefit the community.

Rather than asserting, "This is how it will work," or "This is our interpretation," I would expect them to say, "We've provided this option to meet your needs and give you more freedom."

In my project , I don't use a language service provider within the tsconfig. Similarly, there's an unnecessary exclude exists. I'm not inclined to retain unnecessary configurations. I believe that editing the tsconfig is beyond the scope of Next.js and instead of directly modifying a file (which is a risky operation), it should provide warnings or suggestions.

[david-morris]

My understanding is that next.js maintainers got tired of supporting people having issues with incorrectly configured tsconfig.

They made the decision to automatically write these changes because they've already decided that they're not bothered by serruptitiously and persistently modifying files on computer systems that they have not been authorized to access. At least, not as much as they're bothered by diagnosing incorrect tsconfigs.

So that's why I found it more useful to post technical information about situations where nextjs edits break tsconfigs. That's more likely to lead to change.

[steve-taylor]

I think that the XZ fiasco shows the risks of losing our composure while discussing open-source software.

It behooves us to be friendly and fact-focused, even when maintainers have made choices which we feel affect us negatively or overstep boundaries.

Let's be real. Next.js isn't an open source labor of love. It was created first and foremost to sell egress.

[caly-quilt]

very strange/undesirable behavior to automatically add ".next/types/**/*.ts" into the include field.

i am going to patch our version of next.js to not do this, but next.js should have this only as an opt-in, or at the very least, offer an opt-out. this increases the coupling between next.js and TS as well so any breaking changes to TS could break next.js.

[david-morris]

Please share the patch, I'd be interested in using it.

[kolloch]

I am trying to use next.js with https://github.com/aspect-build/rules_js in Bazel.

tsconfig.json is read-only in that case and next.js terminates with an error failing the build. Please at least add an option to disable this behavior.

[willjschmitt]

A workaround approach I'm using for our Windows build with Bazel and rules_js is to rename tsconfig.json in the project root to something like tsconfig_foo.json and then use that as a target for any ts_project targets in the project. This then allows next.js to write out its own tsconfig.json, which I think is safe for now, since all of our typescript content is otherwise already transpiled by Bazel by the time nextjs picks it up. We only ran into this on Windows, since Bazel on Windows doesn't have sandboxing support, otherwise our Linux builds seem happy enough because next.js doesn't interpret the project as Typescript in a sandboxed build without the typescript files showing up

[adrian-gierakowski]

Could someone please document what's the minimal content of tsconfig file which will prevent next from modifying it? Thanks!

[Willem-Jaap]

The tsconfig of create-next-app should be a good starting point: https://github.com/vercel/next.js/blob/2a88a093734975318f790d313c76c0b1f936dbe3/packages/create-next-app/templates/app-empty/ts/tsconfig.json

[adrian-gierakowski]

Thanks!

[vinnymac]

Here is an updated patch for 14.2.5 that supports only disabling tsconfig rewriting after the first setup.

https://gist.github.com/vinnymac/efa90137f8c7026490c4b19f8ab73286

[TzviPM]

For anyone else struggling with this, I came across this issue when using a composite tsconfig with separate configs for test and non-test files. Adding the following to my next.config.js worked for me:

typescript: {
  tsconfigPath: 'tsconfig.app.json',
},

tsconfig.app.json is the relative path to my app's tsconfig. My tests use tsconfig.test.json and generally, my tsconfig.json is simply:

{
  "compilerOptions": {
    "composite": true,
  },
  "references": [
    {
      "path": "./tsconfig.app.json"
    },
    {
      "path": "./tsconfig.test.json"
    }
  ]
}

[Yumee-Dev]

Thank you! ❤️

It's been a real challenge since official docs mention only the ignoreBuildErrors flag. Yep, they also mention the config-shared.ts file but do it so subtly that I'd never looked there if I didn't see your advice.

[maxxheth]

Looks like its overrides the whole file now, so this no longer unfortunately works. =/

[colinmcparland]

This worked for me!!

[maxxheth]

Thank you @vinnycodes! I'll second this as the go-to fix for this frankly asinine, lazy hack that doesn't really deserve the distinction of being called a feature. I really, really wish @TzviPM's fix would've worked out because the less you have to touch someone else's code, the better, but Next.js now unfortunately overrides tsconfig.json outright! =/

Serious question for the maintainers behind this: Assuming for the sake of argument that there are certain devs who constantly bother you ad nauseam with stupid questions and complaints about how they can't get their TS config to work with Next.js (which is understandably annoying after a certain point, I'll grant that), don't you think that perhaps updating your docs, publishing a tutorial on your blog, providing a standard TS config for everyone to opt into at their leisure, and then pointing everyone towards those resources would've been the saner choice?

Worse yet, what's stopping you from choosing to modify other files in an app workspace with a hard-coded approach if you think this is justifiable? Literally everyone else in the open source community informs their users about how to do things the "right" way or in an ideal way to get things to work WITHOUT FORCING THEM by default to do things one way or the other. If they can't hack it, it's on them. Don't make the rest of us suffer just because somebody else can't bother to figure it out, please!

[leerob]

@maxxheth I am sorry you are frustrated here, but please follow our code of conduct for the community.

[TylerNRobertson]

This is still an issue. Im just "excluding" whatever next dev overrides for now. I have what I want in my tsconfig's and know what types I want to check, making next dev do this as a side effect really just makes no sense and honestly leads to potentially breaking things for a project.

Also, I would love to understand why ".next/types/**/*.ts" is even included at all, TS checks types during compilation and you also can configure your IDE to show in type issues in real-time, with this included type-checking and compiles would take way longer than they needed to. Removing it has had no downsides from what I have seen and type-checking still works as expected across the multiple apps we have

If anything, it should just be its own one off command used in the setup of a nextjs project or to be ran one off, not randomly ran inside of the startup for the dev server, that's just confusing and the docs don't warn about it at all.

[ScottMorse]

[adrian-gierakowski]

💯

[adrian-gierakowski]

Why was this message removed? I also just got 2 follow up messages (sent by @ScottMorse) in my inbox and I can’t see them here? Was he censored?

[leerob]

Hey y'all, sorry we haven't replied with more details here. I'll surface this to our team and we can take a look. I don't have a timeline for a fix I can commit to, but wanted to let you know we hear you here.

Best way to help us prioritize is to update the main message, as we frequently sort by top upvotes when planning and prioritizing. Please refrain from throwing +1 like messages on the thread without more context or details, as it sends unnecessary notifications to the group and will not help with prioritization.

[shaneosullivan]

@leerob any update here, this is amazingly frustrating

[taheramr]

any updates on this? we have a monorepo with multiple tsconfigs that uses extends. Running next dev overrides the includes field especially if we changed the out directory to some dynamic folder name based on the build enviornment.

Can we please have a way to opt out? this is making every change very complicated in the review process as we sometimes add the change to the PR/CR and it is really pointless.