[@rollup/plugin-typescript] { compilerOptions: { module: "nodeNext" } } overwritten when coming from "extends" in tsconfig.json

[jessevanassen]

• Rollup Plugin Name: @rollup/plugin-typescript
• Rollup Plugin Version: 11.1.3
• Rollup Version: 3.29.1
• TypeScript version: 5.2.2
• Operating System (or Browser): Ubuntu 22.04.3 LTS
• Node Version: 20.4.0
• Link to reproduction: https://stackblitz.com/edit/rollup-repro-su4nqt?file=tsconfig.json,tsconfig.base.json,rollup.config.js

Expected Behavior

I have two typescript config files: tsconfig.base.json and tsconfig.json.
In the tsconfig.base.json I have { compilerOptions: { module: "nodeNext" } }.
tsconfig.json extends tsconfig.base.json.

When I run the typescript config, I expect that it takes the module: "nodeNext" into account that I configured in the tsconfig.base.ts.

Actual Behavior

The plugin overwrites { compilerOptions: { module: "nodeNext" } } with { compilerOptions: { module: "esNext" } }. This produces the following error with TypeScript 5.2 and up (see also microsoft/TypeScript#54567):

(!) Plugin typescript: @rollup/plugin-typescript TS5110: Option 'module' must be set to 'NodeNext' when option 'moduleResolution' is set to 'NodeNext'.

Additional Information

Cause of the bug

https://github.com/rollup/plugins/blob/typescript-v11.1.3/packages/typescript/src/options/tsconfig.ts#L155-L196

export const DEFAULT_COMPILER_OPTIONS: PartialCompilerOptions = {
  module: 'esnext',
  skipLibCheck: true
};

// ...

ts.parseJsonConfigFileContent(
  {
    ...tsConfigFile,
    compilerOptions: {
      ...DEFAULT_COMPILER_OPTIONS,
      ...tsConfigFile.compilerOptions
    }
  },
  // ...
);

This block gets the JSON parsed tsConfigFile that's used to process the project (in the reproduction, thats ./tsconfig.json), adds the default options to the compilerOptions, and passes it on to TypeScript to completely parse the file, fill in defaults, etc.

However, if the tsconfig.json contains an extends which defines the module, the tsconfig.json ends up like this:

{
  "compilerOptions": {
    module: 'esnext',
    skipLibCheck: true,
    composite: true,
  },
  extends: "./tsconfig.base.json",
}

These compilerOptions take precedence over the one in the tsconfig.base.json, effectively overriding the project's module setting.

Workaround

Move / copy { compilerOptions: { module: "nodeNext" } } to the tsconfig.json file.
This way, ...tsConfigFile.compilerOptions overwrites the property from ...DEFAULT_COMPILER_OPTIONS. However, it does lead to repetition that the extends should solve.

[romainmnr]

I'm facing the same issue...

Move / copy { compilerOptions: { module: "nodeNext" } } to the tsconfig.json file.

This workaround works, but we loose all the purpose of extending a config...

[renke0]

Explicitly adding it to the plugin declaration also works. Not ideal, but IMO it's better than having to change tsconfig.json.

plugins: [typescript({ module: 'nodeNext' })]

[sam-mfb]

you can also dynamically add it to to the plugin declaration using something like this in a rollup.config.mjs file (or .cjs file with some modifications):

import {
  parseJsonConfigFileContent,
  sys
} from "typescript"
import { readFileSync } from "fs"

const getTsConfig = configFilePath => {
  const configFile = readFileSync(configFilePath, "utf8")
  const configObject = JSON.parse(configFile)
  const configParseResult = parseJsonConfigFileContent(
      configObject,
      sys,
      process.cwd()   )
  return configParseResult
}
const configObj = getTsConfig("./tsconfig.rollup.json")

// other stuff

plugins: [typescript({
  module: configObj.options.module === 199 ? "nodeNext" : undefined //199 is what the typescript enum value ModuleKind.NodeNext resolves to
})]

Presumably some version of the getTsConfig function above could be used to actually fix the readTsConfigFile that is the source of the problem. the basic issue is that it uses ts.readConfigFile() rather than ts.parseJsonConfigFileContent() to parse the tsconfig.json file and so it doesn't handle walking through the extends files. i apologize i don't have time to figure that out and do a PR now.

[jelovac]

Run into this issue as well.

The affected code is located here:

• https://github.com/rollup/plugins/blame/92daef00b0da30de172868d4e0792c8686da0045/packages/typescript/src/options/tsconfig.ts#L76
• https://github.com/rollup/plugins/blame/92daef00b0da30de172868d4e0792c8686da0045/packages/typescript/src/options/tsconfig.ts#L106

I believe that the whole tsconfig.ts module is due for a refactor as its current behavior is not correct and misleading.

The following discussion might help with resolution: microsoft/TypeScript#44573 . There I found mention of https://github.com/dominikg/tsconfck package which can help with parsing of tsconfig files.

[stale]

Hey folks. This issue hasn't received any traction for 60 days, so we're going to close this for housekeeping. If this is still an ongoing issue, please do consider contributing a Pull Request to resolve it. Further discussion is always welcome even with the issue closed. If anything actionable is posted in the comments, we'll consider reopening it. ⓘ