rollup / plugins

🍣 The one-stop shop for official Rollup plugins
MIT License
3.64k stars 591 forks source link

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

Open jessevanassen opened 1 year ago

jessevanassen commented 1 year ago

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 https://github.com/microsoft/TypeScript/pull/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 commented 11 months ago

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 commented 9 months ago

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 commented 3 months ago

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 commented 1 week ago

Run into this issue as well.

The affected code is located here:

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: https://github.com/microsoft/TypeScript/issues/44573 . There I found mention of https://github.com/dominikg/tsconfck package which can help with parsing of tsconfig files.