Issue Station
Sign In
Tools hereToolbox

nextjs - ✅(Solved) Fix Module resolution ignores import aliases for dependencies [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vercel/next.js#93295•Fetched 2026-04-28 06:23:22
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
avivkelleravivkeller
Participants
avivkelleravivkeller
Timeline (top)
cross-referenced ×1issue_type_added ×1labeled ×1subscribed ×1

Error Message

  1. You should see an error similar to: One should expect #lodash to be resolved as the lodash dependency, and not throw an error, as it currently does.

Fix Action

Fixed

PR fix notes

PR #1151: fix: include package.json#imports re-maps in traced files

Description (problem / solution / changelog)

Next's NFT tracer does not appear to follow the imports field in package.json, so packages only reachable via subpath remaps (e.g. @mathjax/src's "#mhchem/*" -> "mhchemparser/esm/*") are missing from the traced server bundle, and built-time and runtime fails to resolve them in the Cloudflare adapter.

copyTracedFiles now scans every traced package.json for an imports field and, for any bare-specifier remap target, resolves the target package from the consumer's real location and pulls its source files in.

This is tested via https://github.com/opennextjs/opennextjs-cloudflare/pull/1231 with a reproduction for https://github.com/opennextjs/opennextjs-cloudflare/issues/1229 (would be a good candidate for monorepo!)

Changed files

  • .changeset/copytracedfiles-imports-remap.md (added, +7/-0)
  • packages/open-next/src/build/copyTracedFiles.ts (modified, +199/-4)
  • packages/tests-unit/tests/build/augmentWithImportsRemaps.test.ts (added, +216/-0)

Code Example

Module not found: Can't resolve '#lodash'

---

"imports": {
    "#lodash": "lodash"
}

---

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 28566
  Available CPU cores: 12
Binaries:
  Node: 22.20.0
  npm: 10.9.3
  Yarn: 1.22.22
  pnpm: 10.14.0
Relevant Packages:
  next: 16.2.4 // Latest available version is detected (16.2.4).
  eslint-config-next: N/A
  react: 19.2.5
  react-dom: 19.2.5
  typescript: 5.9.3
Next.js Config:
  output: N/A
RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://github.com/avivkeller/turbopack-import-aliases-bug-reproduction

To Reproduce

  1. Start the application by running next dev.

  2. Once the development server boots, open the app in your browser.

  3. You should see an error similar to:

    Module not found: Can't resolve '#lodash'

Current vs. Expected behavior

Since the package.json file defines imports as:

"imports": {
    "#lodash": "lodash"
}

One should expect #lodash to be resolved as the lodash dependency, and not throw an error, as it currently does.

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 28566
  Available CPU cores: 12
Binaries:
  Node: 22.20.0
  npm: 10.9.3
  Yarn: 1.22.22
  pnpm: 10.14.0
Relevant Packages:
  next: 16.2.4 // Latest available version is detected (16.2.4).
  eslint-config-next: N/A
  react: 19.2.5
  react-dom: 19.2.5
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Module Resolution

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

Additional context

No response

extent analysis

TL;DR

Review and adjust the imports configuration in package.json to ensure correct module resolution.

Guidance

  • Verify that the imports configuration is correctly formatted and matches the expected resolution for #lodash.
  • Check if there are any conflicts or overrides in other configuration files that might affect module resolution.
  • Test the application with a different import alias to isolate if the issue is specific to #lodash or a broader configuration problem.
  • Consider updating or adjusting the next configuration to ensure compatibility with the imports feature.

Example

No specific code example is provided due to the lack of direct code references in the issue, but reviewing the package.json file for correct imports configuration is crucial.

Notes

The issue seems to be related to the imports configuration in package.json and how Next.js resolves modules. Ensuring the configuration is correct and compatible with the version of Next.js being used is essential.

Recommendation

Apply workaround: Adjust the imports configuration in package.json to correctly resolve #lodash to the lodash dependency, as this seems to be the most direct approach to resolving the module resolution issue described.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#network issue#logging issue#authentication issue#prompt issue#agent setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

nextjs - ✅(Solved) Fix Module resolution ignores import aliases for dependencies [2 pull requests, 1 participants]