Build error after upgrade to TS 5.0 beta

[xaviergonz]

After updating to TS5.0-beta my compilation gives the following error (which does not happen with 4.9 or when this plugin is disabled):

vite v4.1.1 building for production...
✓ 0 modules transformed.
[rpt2] error TS5070: Option '--resolveJsonModule' cannot be specified when 'moduleResolution' is set to 'classic'.

error during build:

    at error (file:///redacted/packages/lib/node_modules/rollup/dist/es/shared/rollup.js:2091:30)
    at Object.error (file:///redacted/packages/lib/node_modules/rollup/dist/es/shared/rollup.js:23586:20)
    at RollupContext.error (/redacted/packages/lib/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:1452:26)
    at /redacted/packages/lib/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:27634:26
    at Array.forEach (<anonymous>)
    at printDiagnostics (/redacted/packages/lib/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:27610:17)
    at Object.buildStart (/redacted/packages/lib/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:28046:17)
    at file:///redacted/packages/lib/node_modules/rollup/dist/es/shared/rollup.js:23785:40
    at async Promise.all (index 1)
    at async PluginDriver.hookParallel (file:///redacted/packages/lib/node_modules/rollup/dist/es/shared/rollup.js:23713:9)
ERROR: command finished with error: command (/redacted/packages/lib) yarn run build exited (1)

My tsconfig is the following:

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "lib": ["dom", "esnext"],
    "moduleResolution": "node",
    "sourceMap": true,
    "resolveJsonModule": true,
    "esModuleInterop": true,
    "noEmit": true,
    "importHelpers": true,
    "declaration": true,
    "declarationDir": "./dist/types",
    "rootDir": "./src",
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "noImplicitThis": true,
    "alwaysStrict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "baseUrl": "./",
    "paths": {
      "*": ["src/*", "node_modules/*"]
    },
    "jsx": "react",
    "experimentalDecorators": true,
    "emitDecoratorMetadata": false,
    "skipLibCheck": true,
    "stripInternal": true,
    "useDefineForClassFields": true,
    "isolatedModules": true
  },
  "include": ["./src"]
}

if I remove resolveJsonModule then I get a lot of errors like

src/index.ts:23:15 - error TS2792: Cannot find module './wrappers'. Did you mean to set the 'moduleResolution' option to 'nodenext', or to add aliases to the 'paths' option?
build: 
build: 23 export * from "./wrappers"

errors that do not disappear even if I actually change moduleResolution from node to nodenext

[agilgur5]

removed issue template

Please don't remove the issue template, it's there for a reason, and your issue is missing many of the details we request from it as well since you removed it...

For instance, you have no repro, no Rollup config, and no package.json with versions, among other problems...

As a fellow OSS maintainer, I'd imagine you're well aware of how problematic issues without a template often are.

debugging what I can

From the little information available, a few things pop up:

[rpt2] error TS5070: Option '--resolveJsonModule' cannot be specified when 'moduleResolution' is set to 'classic'.

This error message suggests that you set moduleResolution: 'classic', but that seems incorrect based on your tsconfig. rpt2 also forces moduleResolution: 'node', since 'classic' is legacy and incompatible.

So that's an odd error message. We don't hard-code this option, we use the enum / identifier from TS itself: ts.ModuleResolutionKind.NodeJs. So that's potentially a TS bug if it's picking up 'classic' instead? 🤔

Also note that rpt2's TS errors are coming from TS itself; rpt2 just forwards the errors, which have the TS error identifier in them. The issue template asks if the same error occurs with tsc, as many errors that are reported here are just TS errors and independent of rpt2.

build: 23 export * from "./wrappers"

This part sounds familiar to #434. I don't know what that code is referencing given how little information is in the issue, but per #434, TS 5.0 beta appears to follow the ESM spec more stringently, and so directory imports no longer work. I'm not sure if that's a directory import -- there is no repro or source code to be found in this issue -- but if it is, please see #434, which is not a bug in rpt2, but rather non-spec code.

That's all I can say given the information available, this is why the issue template asks for much more information.

[xaviergonz]

Thanks for looking into it even though I didn't fill in the template!

So that's an odd error message. We don't hard-code this option, we use the enum / identifier from TS itself: ts.ModuleResolutionKind.NodeJs. So that's potentially a TS bug if it's picking up 'classic' instead? 🤔

Actually that might be the issue, apparently TS renamed ModuleResolutionKind.NodeJs to ModuleResolutionKind.Node10 for v5.0, so I guess NodeJs is returning undefined, which defaults to classic somehow

v5: https://github.com/microsoft/TypeScript/blob/6bbdcaa14667772525b25a43f146b21352d7f29f/src/compiler/utilities.ts#L8323

v4: https://github.com/microsoft/TypeScript/blob/ccf3d3c5f9b4bc2883d700870ed2dac454050f1f/src/compiler/utilities.ts#L6379

Btw, tsc -c compiles fine

[ezolenko]

0.34.1 seems to work fine with typescript 5.0.4, looks like it was fixed upstream? @xaviergonz do you still see similar errors on current typescript versions?

[xaviergonz]

it worked with the final version. thanks

[agilgur5]

Actually that might be the issue, apparently TS renamed ModuleResolutionKind.NodeJs to ModuleResolutionKind.Node10 for v5.0, so I guess NodeJs is returning undefined, which defaults to classic somehow

Yea looks like this was indeed an upstream TS bug: https://github.com/microsoft/TypeScript/issues/53131. Was fixed in TS 5.0.2. I was gonna suggest that you might want to file upstream and could probably PR a fix for that upstream too since you already found the code references, particularly as it was still beta back in Feb.

Didn't quite get around to writing that timely here, sorry! Think I was recovering from COVID in Feb while simultaneously dealing with (another) re-org at work and heading up a new team from scratch as a result.