Bad @babel/core resolution with Yarn Workspaces hoisting

[marvinroger]

I'm submitting a bug report

Webpack Version:
4.19.1

Babel Core Version:
7.1.2

Babel Loader Version:
8.0.4

Please tell us about your environment:
Windows 10

Current behavior:

When using Yarn Workspaces, we might have the following file tree:

node_modules/
__ @babel/core (7.0.0-beta.42)
__ babel-loader (8.0.4)
packages/
__ webpack-config
____ node_modules/
______ @babel/core (7.1.2)
__ foobar
____ node_modules/
...

There are two @babel/core installs in different locations, because Yarn detected that two packages required two different versions of the package. In my case (from the point of view of the webpack-config package), I need @babel/core (7.1.2) and babel-loader (8.0.4).

Unfortunately, in this case, babel-loader (8.0.4) does a require('@babel/core'), which resolves relative to its own node_modules/ folder, which is @babel/core (7.0.0-beta.42).

Expected/desired behavior:

• What is the expected behavior?

I expect babel-loader (8.0.4) to require from the context of the package requiring babel-loader, I need it to resolve to the local @babel/core (7.1.2). Except it does not.

I am not sure you can solve the resolution context, but the loader can accept a babelCore option, that way, we would be able to feed the loader with the version we want.

• What is the motivation / use case for changing the behavior?

Yarn Workspace is now stable, and is used a lot in monorepo.

Thanks for your great work! 👍

[loganfsmyth]

What are your various package.json files and what versions do they have?

[marvinroger]

I require @babel/core from one place, only in the webpack-config package (pinned to 7.1.2). The hoisted @babel/core (7.0.0-beta.42) is not required by one of my packages.

[marvinroger]

By the way, adding a nohoist @babel/core to the webpack-config package.json "fixes" the issue, but this is a workaround. There should be a cleaner approach, where we could simply inject the @babel/core we need (resolved in the context of our package).

[loganfsmyth]

As long as webpack-config's code is what references babel-loader in the Webpack config and its package.json loads both babel-loader and @babel/core@7.1.2, then this is a Yarn hoisting bug.

[vikr01]

yarn workspaces has been iffy for me with mixing versions of the same package, which is why I install all babel and other commonly used devDependencies to the root package. In this case @babel/core is a peer dependency of babel-loader, and it seems yarn doesn't check this while installing (you should open an issue ticket there if there isn't already one).

Recreating this myself, I was able to control where @babel/core is being installed by the order in which you install it in packages:

1. remove the @babel/core@7.0.0-beta.42 beta dependency from foobar
2. clean out all node_modules folders
3. run a fresh yarn install
4. add @babel/core@7.0.0-beta.42 back to foobar

The new structure should look like this:

node_modules/
__ @babel/core (7.1.2)
__ babel-loader (8.0.4)
packages/
__ webpack-config
____ node_modules/
__ foobar
____ node_modules/
______ @babel/core (7.0.0-beta.42)
...

I believe the yarn.lock will remember the structure.

An alternative option is to add a dummy babel-loader somewhere (i.e. root of the project or foobar).

[marvinroger]

@vikr01 you are right, the core issue is that Yarn should not hoist packages marked as peerDependencies. I'll open a ticket there. Closing this ticket for now.

Thanks everyone!

[mhuggins]

@marvinroger Was an issue ever opened for this? I'm seeing this error and don't know what the resolution was.

[marvinroger]

yarnpkg/yarn#5705 describes the issue, but it's not fixed yet.