rsnext/test/production/supports-module-resolution-nodenext/tsconfig.json

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

21 lines
515 B
JSON
Raw Normal View History

Stop overriding the user's TS config with defaults during `next build` (#45670) ## Bug The `next build` command is silently overriding the user's tsconfig when it shouldn't be; this results in mismatched behavior between `tsc --noEmit` and `yarn build` and user confusion. For example, a configuration option like `"moduleResolution": "nodenext"`, which is preserved and respected by `next dev`, will be silently overridden to `"moduleResolution": "node"` during `next build`. This change: - Fixes #38854 - (probably fixes) #45452 (I have not verified) - (probably fixes) #41189 (I have not verified) ## Details Next has a concept of both _defaults_ and _permitted options_ when modifying/validating the user's tsconfig. The user's config is only modified if it does not match the _permitted options_. This means that if the user has specified a permitted value like `"moduleResolution": "nodenext"`, it will not be overwritten in the user's config file. However, there was some logic in `runTypeCheck.ts` that did not adequately capture this nuance – instead, it spread all of the defaults into the tsconfig it was building before running typecheck, which meant that if a user had specified an option that was _permitted_ but _non-default_, it would be overwritten, silently, during `yarn build` only. Because Next is already (1) rewriting the TSconfig in `writeConfigurationDefaults` when the user's config doesn't line up with what we're expecting and (2) verifying the user's TSConfig remains correct (in `verifyTypeScriptSetup`) during a `next build`, I believe that it is safe to remove this config-steamrolling behavior. ## Documentation / Examples I believe this is strictly a bugfix; it updates the behavior of `next build` to conform to the same configuration behavior exhibited by `tsc --noEmit` and `next dev`. Since this is already the user expectation, it should not require documentation changes. --------- Co-authored-by: Shu Ding <g@shud.in> Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
2023-02-15 18:11:00 +01:00
{
"compilerOptions": {
"esModuleInterop": true,
"module": "NodeNext",
Stop overriding the user's TS config with defaults during `next build` (#45670) ## Bug The `next build` command is silently overriding the user's tsconfig when it shouldn't be; this results in mismatched behavior between `tsc --noEmit` and `yarn build` and user confusion. For example, a configuration option like `"moduleResolution": "nodenext"`, which is preserved and respected by `next dev`, will be silently overridden to `"moduleResolution": "node"` during `next build`. This change: - Fixes #38854 - (probably fixes) #45452 (I have not verified) - (probably fixes) #41189 (I have not verified) ## Details Next has a concept of both _defaults_ and _permitted options_ when modifying/validating the user's tsconfig. The user's config is only modified if it does not match the _permitted options_. This means that if the user has specified a permitted value like `"moduleResolution": "nodenext"`, it will not be overwritten in the user's config file. However, there was some logic in `runTypeCheck.ts` that did not adequately capture this nuance – instead, it spread all of the defaults into the tsconfig it was building before running typecheck, which meant that if a user had specified an option that was _permitted_ but _non-default_, it would be overwritten, silently, during `yarn build` only. Because Next is already (1) rewriting the TSconfig in `writeConfigurationDefaults` when the user's config doesn't line up with what we're expecting and (2) verifying the user's TSConfig remains correct (in `verifyTypeScriptSetup`) during a `next build`, I believe that it is safe to remove this config-steamrolling behavior. ## Documentation / Examples I believe this is strictly a bugfix; it updates the behavior of `next build` to conform to the same configuration behavior exhibited by `tsc --noEmit` and `next dev`. Since this is already the user expectation, it should not require documentation changes. --------- Co-authored-by: Shu Ding <g@shud.in> Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
2023-02-15 18:11:00 +01:00
"jsx": "preserve",
"target": "es5",
"lib": ["dom", "dom.iterable", "esnext"],
"allowJs": true,
"skipLibCheck": true,
"strict": true,
"forceConsistentCasingInFileNames": true,
"noEmit": true,
"incremental": true,
"moduleResolution": "nodenext",
"resolveJsonModule": true,
"isolatedModules": true
},
"exclude": ["node_modules"],
"include": ["next-env.d.ts", "components", "pages"]
}