vercel / vercel/next.js

[Turbopack] Third-party import statements are not resolved in the order specified in the resolve extensions config

Open
#97,567 0 comments 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Turbopack
Dominant language
JavaScript
Stars
142k
Forks
32.4k
Avg merge
2d 14h
Merged PRs (30d)
351

Description

Link to the code that reproduces this issue

https://github.com/gabrieltrompiz/turbopack-rn-reproduction-app

To Reproduce
  1. Start the application in dev mode (pnpm dev, yarn dev or npm run dev)
  2. Go to localhost:3000 (or whatever port Next is using)
Current vs. Expected behavior

Current: Aliases defined in the Turbopack config are resolved in the order declared for files that are within the same repository, but does not apply that order for imports within third-party dependencies.

In the reproduction app, we import createMMKV from react-native-mmkv. That function is exported from that package by importing it from ./createMMKV/createMMKV. The aliases that I defined in the config should make it so that the import resolves to ./createMMKV/createMMKV.web.js since that takes precedence over the plain .js files (see Next config below), but Turbopack resolves to ./createMMKV/createMMKV.js which breaks the app since it contains React Native dependencies.

This is pretty much reopening https://github.com/vercel/next.js/issues/91117, but back then it was only solved for imports within your app.

Expected: The module aliases should work the same way in imports from third-party dependencies, mimicking how Webpack aliases work

Provide environment information
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.5.0: Tue Jun  9 22:28:24 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6020
  Available memory (MB): 16384
  Available CPU cores: 10
Binaries:
  Node: 24.11.1
  npm: 11.6.2
  Yarn: 1.22.22
  pnpm: 10.26.2
Relevant Packages:
  next: 16.3.1-canary.24 // Latest available version is detected (16.3.1-canary.24).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 5.9.3
Next.js Config:
  output: N/A
Which area(s) are affected? (Select all that apply)

Turbopack

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

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

Additional context

Next config:

const nextConfig: NextConfig = {
  turbopack: {
    resolveAlias: {
      "react-native": "react-native-web",
    },
    resolveExtensions: [
      ".web.js",
      ".web.jsx",
      ".web.ts",
      ".web.tsx",
      ".mdx",
      ".tsx",
      ".ts",
      ".jsx",
      ".js",
      ".mjs",
      ".json",
    ],
    root: __dirname,
  },

  webpack: (config) => {
    config.resolve.alias = {
      ...(config.resolve.alias || {}),
      // Transform all direct `react-native` imports to `react-native-web`
      "react-native$": "react-native-web",
    };
    config.resolve.extensions = [
      ".web.js",
      ".web.jsx",
      ".web.ts",
      ".web.tsx",
      ...config.resolve.extensions,
    ];
    return config;
  },
};

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked turbopack-rn-reproduction-app and run it in dev mode using pnpm dev, yarn dev, or npm run dev. Review the Next config's resolveAlias and resolveExtensions settings, then verify that the third-party react-native-mmkv import selects createMMKV.web.js before createMMKV.js and that the app works in next dev, next build, and next start.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, next.js
Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.