The development mode no longer works with a library imported via Yalc

[keepeek-rd]

Verify canary release

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

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro
Binaries:
  Node: 16.13.1
  npm: 8.5.3
  Yarn: 1.22.17
  pnpm: N/A
Relevant packages:
  next: 12.1.0
  react: 17.0.2
  react-dom: 17.0.2

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

Describe the Bug

Since I use version NextJS "12.1.0", when I launch my application in development mode, I have an error in the server console:

$ next dev
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
info  - Loaded env from C:\dev\dev\XXX\XXX-core\.env.local
info  - Loaded env from C:\dev\dev\XXX\XXX-core\.env
warn  - SWC minify release candidate enabled. https://nextjs.org/docs/messages/swc-minify-enabled
Prepare XXX build client side
Prepare XXX build server side
error - ./.yalc/@XXX/XXX-customers/dist/customers/XXX/index.js
Module parse failed: Cannot use 'import.meta' outside a module (219:16)
File was processed with these loaders:
 * ./node_modules/next/dist/compiled/@next/react-refresh-utils/loader.js
 * ./node_modules/next/dist/build/webpack/loaders/next-swc-loader.js
You may need an additional loader to handle the result of these loaders.
|                 // still a Refresh Boundary later.
|                 // @ts-ignore importMeta is replaced in the loader
>                 import.meta.webpackHot.accept();
|                 // This field is set when the previous version of this module was a
|                 // Refresh Boundary, letting us know we need to check for invalidation or

Note that before I was using version 12.0.4 and that I use yalc link to reference my custom library locally

Expected Behavior

my application launches correctly in development mode (without error) and manages to use my custom library imported with "yalc link"

To Reproduce

Use a next application in version 12.1.0, reference an external NPM library with "yalc link"

[keepeek-rd]

I changed the extension of the files generated by the bundler of my custom package to ".cjs" and I no longer have the problem...
this seems to be related to the nextjs changes made here:
#33637

Related code:
62b1704

[eric-burel]

I can also reproduce when using Yalc, ESM exports only and 12.1.0. The Yalc symlink is treated as a local package instead of an external, and thus is built again with Next, with "import" transformed as "require", leading to issues with subdependencies of the ESM dependency.

The packages works ok when I publish them on NPM.

There might be unrelated issue about how cjs+esm exports works as well and maybe a similar issue with Yarn link.

[sangotaro]

probably same issue of #34796
cc: @timneutkens

[eric-burel]

Here is a minimal reproduction: https://github.com/VulcanJS/repro-bug-yalc-next-12-1

A package that uses ES modules and depends on another package that also uses ES modules (say react-konva) cannot be linked via Yalc (and maybe with yarn link as well though I have only tested Yalc), as it will be treated as a local package by Next instead of an external. Next is probably tricked by the symlink to a local package, and thinks it should build that package.

[eric-burel]

I am trying to dig the code in order to help fixing this.
It seems that the code that handle this is located in "packages/next/build/webpack-config.ts".

The latest commit that modifies it is: 82001f2

It could be interesting to test before and after that commit specifically, or at least debug what happens when it resolve a linked ES module.

There is a unit test demo in "test/unit/webpack-config-overrides.test.ts", maybe we can check if it works when the path is outside Next.js directory (for symlinks) OR contains a .yalc in the path (I am not sure if we can solve this without specific rules for specific kind of tools).

[eric-burel]

Same issue with Yarn 3 workspaces, with Next 12.1.6, that also use a symlink.
To reproduce:

git clone https://github.com/VulcanJS/vulcan-npm/tree/feature/remix-starter
cd vulcan-npm
yarn
cd starters/next
yarn run build

I get:

Failed to compile.

../../packages/mongo/mongoParams.ts
Module parse failed: The keyword 'interface' is reserved (79:0)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| 
| // TODO: should we use TModel or Vulcan document here??
> interface FilterFunctionOutput {
|   selector: FilterQuery<any>;
|   options: QueryOptions;

Import trace for requested module:
../../packages/mongo/client/index.ts
../../packages/react-hooks/dist/index.js
./src/pages/vn/admin/crud/VulcanUser.tsx


> Build failed because of webpack errors

So @vulcanjs/mongo, which is a package of my monorepository, handled via Yarn 3 workspaces, and this symlinked in starters/next/node_modules pointing to ../../packages/mongo, is somehow understood as some local code.
Next tries to read the actual TS source instead of respecting the package.json and reading dist/index.

Everytime the dependency of the dependency is specifically affected, not necessarily the first-level dependency (here "@vulcanjs/react-hooks" is ok, but not "@vulcanjs/mongo" that it depends on ; both are ES modules with exports map).

[TheMikeyRoss]

I'm currently facing this issue as well.
I'm developing a UI component library and I'm using yalc to publish it locally. And when I do yalc add my-library inside a freshly created next.js app I get an error that the module was not found

[righteousgambit]

+1

Next 14.0.4

Import trace for requested module:
./node_modules/@babel/runtime/helpers/interopRequireDefault.js
./node_modules/react-syntax-highlighter/dist/cjs/styles/prism/index.js
./src/Container/ChatContainer/LeftSide.tsx
./src/pages/learnChat.tsx
⨯ ./node_modules/@babel/runtime/helpers/interopRequireDefault.js
Module parse failed: Cannot use 'import.meta' outside a module (40:16)
| // still a Refresh Boundary later.
| // @ts-ignore importMeta is replaced in the loader
`> import.meta.webpackHot.accept();
| // This field is set when the previous version of this module was a
| // Refresh Boundary, letting us know we need to check for invalidation or

[vincent-lecrubier-skydio]

Same here, anyone found a solution to this? This is blocking us from upgrading to NextJS 14

[sarhanm]

I'm facing the same issue.

NextJS 14.0.1 works fine for me. The break occurs in 14.0.2

I just tried 14.1.0. No fix yet.

I'm using yarn 4.0.1 with local dependencies mapped via workspace:^

[eduard-malakhov]

I'm having the same issue with v14.0.4, but not with v14.0.1.

[sarhanm]

Looks like if i remove

"type": "commonjs",

from all my local package's package.json files, my problem goes away.

Not a real fix on vercel's side, but can get you unblocked.

[tjx666]

I occur the same error message when I upgrade nextjs 13 to 14, but the error related to package: @mui/icons-material.

my solution is:

rm -rf node_modules yarn.lock && yarn install

[joeplaa]

I narrowed the problem down to version >14.1.4 in our application. Every Next version higher than that would block the dev mode.

For me adding "@babel/runtime": "^7.24.6" to the resolutions in package.json helped fix it. When running yarn install, it removed duplicate/stale/old versions. After that I removed the "resolution" and everything still works fine.

"resolutions": {
  "@babel/runtime": "^7.24.6"
},

[pirtlj]

I just had the same issue <3 thanks @joeplaa

[developerr-ayush]

i have also faced same issue and just updated nextjs app

[vara855]

Seems that fix for that issue in that commit #60563

I've fixed that for my next.js version (13.5) with a webpack hack

const transpilePackages = ['...']; // you should have your packages here

const transpilePackagesRegex = new RegExp(
  `[/\\\\]node_modules[/\\\\](${transpilePackages?.map((p) => p.replace(/\//g, '[/\\\\]')).join('|')})[/\\\\]`,
);

function createWebpackConfig() {
  return (config) => {
    const oneOfRule = config.module.rules.find((rule) => 'oneOf' in rule);
    oneOfRule.oneOf.forEach((rule) => {
      if (
        'use' in rule &&
        Array.isArray(rule.use) &&
        rule.use.some((u) => typeof u === 'string' && u.includes('react-refresh'))
      ) {
        rule.exclude = [rule.exclude, transpilePackagesRegex];
      }
    });

    return config;
  };
}

So that monkey patching fixed all errors... This isn't the best solution, and it's similar to how I used to manage the configuration for CRA. But we have to go with what we have...