Turbopack: Resolve aliases from import location for transitive deps

[cdown]

When resolveAlias is configured, the alias is currently resolved from project_path instead of from the original import location. This can cause issues when transitive dependencies try to import the aliased package, because the package might only exist in the transitive dependency's node_modules, not in the project root's node_modules.

The bug was introduced in commit f8cd413. The intent there was to add support for conditional aliases, but it also changed the resolution base from the import site to the project root, which causes this issue.

Use None for the lookup path, which allows the resolver to use the original import location. This means:

• Direct dependencies continue to work (resolution happens from project root)
• Transitive dependencies now work (resolution happens from their location)

Fixes: #88540

[nextjs-bot]

Allow CI Workflow Run

• approve CI run for commit: 2354f9c

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[nextjs-bot]

Allow CI Workflow Run

• approve CI run for commit: 2354f9c

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[nextjs-bot]

Allow CI Workflow Run

• approve CI run for commit: 2354f9c

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[cdown]

cc @sokra as author of f8cd413 for opinion

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing cdown:cdown/2026-01-22/alias_transitive_deps (2354f9c) with canary (0866832)}

Summary

✅ 17 untouched benchmarks
⏩ 3 skipped benchmarks¹

Footnotes

1. 3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[sokra]

"It's not a bug, it's a feature"

yeah, but actually it's intentionally resolving from the project root. You write the request in the next.config, so it should resolve from there. That's quite important e. g. for relative requests: "./some/file.js".

But there are usecases where you want to resolve from the original location. We discussed that before and that makes sense, but it should be opt-in. Maybe:

resolveAlias: {
  "foo": "bar", // resolves from project root
  "foo": {
    request: "bar",
    from: "original" // resolves from original location
  },
  "foo": {
    result: require.resolve("foo") // doesn't resolve, but uses this already resolved path
  }
}

[cdown]

Thanks for coming back!

The reasoning for relative paths makes sense, a couple of clarifying questions:

1. For bare specifiers like test-pkg/foo going to test-pkg/foo/alt, is project-root resolution also intentional? In this case, Node's resolution algorithm would naturally find the package from wherever it's imported, so resolving from project root seems to change that behavior in a way that breaks transitive deps.
2. The webpack config equivalent works for transitive dependencies as far as I can see, is that difference in behavior intentional, or should Turbopack match webpack here?

I am not super familiar with Turbopack and am trying to put in some PRs to get more familiar and spelunk around the codebase, so it's possible that I am missing some historical context here :-)