Permitted TypeScript moduleResolution field is silently ignored during build step

[nopelluhh]

Verify canary release

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

Provide environment information

Operating System:
Platform: linux
Arch: x64
Version: Ubuntu 20.04.0 LTS Wed Jul 20 2022 15:07:23 GMT-0700 (Pacific Daylight Time)
Binaries:
Node: 16.14.2
npm: 7.17.0
Yarn: 1.22.10
pnpm: N/A
Relevant packages:
next: 12.2.3-canary.14
eslint-config-next: N/A
react: 18.2.0
react-dom: 18.2.0

warn - Latest canary version not detected, detected: "12.2.3-canary.14", newest: "12.2.3-canary.15".
Please try the latest canary version (npm install next@canary) to confirm the issue still exists before creating a new issue.
Read more - https://nextjs.org/docs/messages/opening-an-issue

NOTE: I was unable to install 12.2.3-canary.15, it doesn't seem to exist on NPM at the time of creating this issue

What browser are you using? (if relevant)

N/A

How are you deploying your application? (if relevant)

N/A

Describe the Bug

Running next build ignores the moduleResolution field if it contains a value other than nodejs, even when using a permitted type as outlined here:

next.js/packages/next/lib/typescript/writeConfigurationDefaults.ts

Lines 59 to 61 in d895a50

	ts.ModuleResolutionKind.NodeJs,
	ts.ModuleResolutionKind.Node12,
	ts.ModuleResolutionKind.NodeNext,

This means that builds that pass direct type checking via tsc will fail to build if node12 or nodenext are used.

I did a bit of digging and it appears this is because while writeConfigurationDefaults allows parsedValues options above, getRequiredConfiguration only returns parsedValue and which overrides the user's config:

next.js/packages/next/lib/typescript/runTypeCheck.ts

Lines 39 to 47 in 0d80b11

	const requiredConfig = getRequiredConfiguration(ts)
	const options = {
	...effectiveConfiguration.options,
	...requiredConfig,
	declarationMap: false,
	emitDeclarationOnly: false,
	noEmit: true,
	}

If this is not the expected behavior I'm happy to attempt a PR to fix, but wanted to confirm before giving it a shot.

Expected Behavior

Running yarn build should respect the moduleResolution field when it contains a permitted value other than nodejs.

Link to reproduction

https://stackblitz.com/edit/vercel-next-js-wtfonr

To Reproduce

Run yarn build (and also observe that yarn tsc does not error)

[harrysolovay]

I'm also running into this issue.

I have my tsconfig's moduleResolution set to "NodeNext" so that I can use non-root exports.

For instance:

import * as M from "capi/frame_metadata";
// ...

The following error occurs upon running next build.

./components/layout/sidebar/ExtrinsicsList.tsx:1:20
Type error: Cannot find module 'capi/frame_metadata' or its corresponding type declarations.

> 1 | import * as M from "capi/frame_metadata";
    |                    ^
  2 | import classNames from "classnames";
  3 | import * as H from "hooks";
  4 | import Link from "next/link";

I'd also recommend that setting the tsconfig field auto-disable the import/no-unresolved lint, which does not account for such NodeNext import path specifiers.

[karl-kallavus]

Same. I'm also running into this problem.

package.json

"exports": {
    ".": {
      "import": "./esm/index.js",
      "require": "./script/index.js",
      "types": "./types/index.d.ts"
    },
    "./test-util": {
      "import": "./esm/test-util/test.js",
      "require": "./script/test-util/test.js",
      "types": "./types/test-util/test.d.ts"
 },

And same error occurs upon running next build.

Seems like quite a big problem that type resolution of package.json exports is unsupported.

[github-actions]

Please verify that your issue can be recreated with next@canary.

Why was this issue marked with the please verify canary label?

We noticed the provided reproduction was using an older version of Next.js, instead of canary.

The canary version of Next.js ships daily and includes all features and fixes that have not been released to the stable version yet. You can think of canary as a public beta. Some issues may already be fixed in the canary version, so please verify that your issue reproduces by running npm install next@canary and test it in your project, using your reproduction steps.

If the issue does not reproduce with the canary version, then it has already been fixed and this issue can be closed.

How can I quickly verify if my issue has been fixed in canary?

The safest way is to install next@canary in your project and test it, but you can also search through closed Next.js issues for duplicates or check the Next.js releases. You can also use the GitHub template (preferred), or the CodeSandbox or StackBlitz templates to create a reproduction with canary from scratch.

My issue has been open for a long time, why do I need to verify canary now?

Next.js does not backport bug fixes to older versions of Next.js. Instead, we are trying to introduce only a minimal amount of breaking changes between major releases.

What happens if I don't verify against the canary version of Next.js?

An issue with the please verify canary that receives no meaningful activity (e.g. new comments that acknowledge verification against canary) will be automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue, with the required reproduction, using next@canary.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the 👍 reaction on the topmost comment (please do not comment "I have the same issue" without repro steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues

[nopelluhh]

hey @jankaifer, i've verified that this is still a problem with the latest canary.

new sandbox: https://stackblitz.com/edit/vercel-next-js-cpvefa

repro steps:

1. observe that npx tsc succeeds
2. observe that npm run build fails type checking (it also seems oddly slow given the project size but that's unrelated)

[qrohlf]

I have spun up a new PR that aims to resolve this issue: #45670

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.