Linaria: Webpack 5 support

[arendjr]

Describe the enhancement

Webpack 5 was released recently. It would be nice if Linaria supports it out-of-the-box.

Motivation

I have a project that is based on Webpack 4 which also uses Yarn PnP. I'm running into issues there with Linaria as soon as modules containing Linaria tags use imports from other modules. I have tracked this down to enhanced-resolve and I suspect it could be related to #658 as Yarn PnP requires some plugins to work with Webpack 4.

However, Webpack 5 and enhanced-resolve 5 (which go hand-in-hand) support Yarn PnP out-of-the-box. I believe once Linaria supports these, everything should "just work".

Possible implementations

A first step would be upgrading to enhanced-resolve@5. I don't know which other steps are necessary.

Related Issues

• #658: Support Webpack Resolver Plugins in Loader

[Anber]

Hi @arendjr
It looks like the support of Webpack 5 introduces a lot of changes and I'm afraid that it will postpone the already drawn-out release.
Our next main goal after 2.0 is splitting linaria to separate packages in order to support different bundlers and environments without excess dependencies in the main package, and the loader for Webpack 5 with yarn pnp support is my personal priority goal :)

[Anber]

The PR with migration to monorepo https://github.com/callstack/linaria/pull/687

[Anber]

Webpack 5 loader has been published (@linaria/webpack5-loader) but it looks like it wasn't enough for supporting yarn pnp.

[arendjr]

Awesome! I just tried upgrading, and indeed I'm running into an issue:

ERROR in ./src/index.tsx
Module build failed (from ./.yarn/$$virtual/@linaria-webpack5-loader-virtual-56c8db5b3e/0/cache/@linaria-webpack5-loader-npm-3.0.0-beta.0-00c2e4bddc-9057e5d341.zip/node_modules/@linaria/webpack5-loader/lib/index.js):
Error: @linaria/babel tried to access @linaria/shaker, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

This is due to PnP indeed, the last line described the issue pretty clearly. I think it should be easily fixable, but it probably requires some careful scanning that since the monorepo migration there are no undocumented dependencies between packages.

I didn't get this error with Linaria 2, which actually makes me a little bit hopeful. It's still possible once the above is fixed that the original enhanced-resolve issue is fixed too :)

[Anber]

Yep, @linaria/shaker should be added to devDependencies. It's a package with evaluation strategy and I forgot to mention it in the documentation.

[arendjr]

Does devDependencies suffice, or should it be dependencies? IIUC, devDependencies wouldn't be installed transitively, which I think is necessary here.

[Anber]

Only @linaria/core and @linaria/react should be dependencies. The rest of the packages can be dev.

[arendjr]

Oh, you mean that's what I should do as a user? I think what Yarn is telling us is that it's the responsibility of the @linaria/babel package to specify its dependencies correctly. Along with @linaria/shaker, these seem to be all missing from the dependencies in its package.json:

• @babel/plugin-proposal-export-namespace-from
• @babel/plugin-transform-modules-commonjs
• @babel/plugin-transform-runtime
• @babel/runtime
• babel-plugin-transform-react-remove-prop-types

[arendjr]

I think this is also related to #700 .

[Anber]

It's a tricky part. Since @linaria/shaker is optional and can be replaced in a config with another evaluator, we cannot force users to install it even as a peerDependency. I don't sure yet, but maybe it will be possible to add a better notification about missed strategy package. But for now, you need to add that package as a devDependency to your project.

[arendjr]

Alright. I might suggest not using it as a default then, if it requires a package you don't want to force users to install.

That said, I've got everything working with Webpack 5 and PnP now. And Linaria components referencing each other across files works as well now. So I'm all happy! Thanks so much!