Webpack 5 support

[missing1984]

What would you like?

Webpack 5 is released 2 weeks ago. https://webpack.js.org/blog/2020-10-10-webpack-5-release/, does Cypress has any plan upgrade its webpack preprocessor to support webpack 5?

Why is this needed?

Most of the open-source projects are moving towards webpack 5. For a project that already using webpack 5 it will be great to have it work out of the box.

[Reiterkk]

That would be very desirable in any case. With webpack 5.1.3, webpack-cli 4.1.0, cypress 5.4.0 and webpack-preprocessor 5.4.8 I currently get the error:

For example, when I try to import FullCalendar, it aborts completely:

Is there a recommended combination of webpack, webpack-cli, cypress and webpack-preprocessor that currently works together?

[dmtrKovalenko]

Question @Reiterkk can you please provide at least a little way to reproduce the errors. Many thanks

[vahidd]

@Reiterkk Did you manage to fix it?

[csvan]

Should probably be kept in mind that while Webpack 5 is in stable, it's not very stable at the moment, and the ecosystem has yet to catch on. Cypress should probably give it a few months before migrating for the sake of stability.

[dmtrKovalenko]

This was already fixed, but we cannot merge it because it breaks react-scripts.

[Reiterkk]

Question @Reiterkk can you please provide at least a little way to reproduce the errors. Many thanks

Sorry for not being able to provide more information at the moment, because I'm very busy with some other projects currently. Glad to hear, you found a way to fix it and I'm looking forward for the solution, once it doesn't break anything anymore.

[twgraham]

Is there no way to release a new breaking version of it (or prerelease). I imagine there are many others like myself who don't rely on CRA (or react for that matter) that require webpack 5 support.

[dmtrKovalenko]

cc @JessicaSachs

[rohrlaf]

@Reiterkk I just tried this out with Cypress 4 after a Webpack 5 upgrade of our component playground React-Styleguidist. I ran into the same error message, and most suggestions I found ended up here: https://docs.cypress.io/api/events/catalog-of-events.html#Uncaught-Exceptions

After adding the code below, the Cypress tests run through and the components behave just like before:

// likely want to do this in a support file
// so it's applied to all spec files
// cypress/support/index.js

Cypress.on('uncaught:exception', (err, runnable) => {
  // returning false here prevents Cypress from
  // failing the test
  return false
})

[dmtrKovalenko]

While we cannot release the final version of preprocessor with webpack v5 support – I released the temporary version of this package that supports webpack v5 – https://www.npmjs.com/package/cypress-webpack-preprocessor-v5

Install the temporal version

yarn add cypress-webpack-preprocessor-v5

[paulfalgout]

Hmm. I've been using cypress-webpack-preprocessor with webpack 5 now for a bit and the only issue for us is the peer dependency warning. It seems like adding an || ^5.1.0 to that would work for at least some people without really being a breaking change.

https://github.com/RoundingWell/care-ops-frontend/blob/develop/package.json#L106

[kishok]

hi i am using angular 11 with webpack 5 and cypress-webpack-preprocessor-v5, in my test case the test fails while mounting target component that contains custom elements.

and my webpack config used for test runner:

`const wp = require('cypress-webpack-preprocessor-v5');
const { CODE_COVERAGE } = process.env;
const path = require('path');
import root from "./helpers";

const loaders = [
{
test: /.ts$/,
exclude: [/node_modules/, /test.ts/, /polyfills.ts/],
use: [
{
loader: 'ts-loader',
options: {
transpileOnly: true
}
},
{
loader: 'angular2-template-loader'
}
]
},
{
// Mark files inside @angular/core as using SystemJS style dynamic imports.
// Removing this will cause deprecation warnings to appear.
test: /[/\]@angular[/\]core[/\].+.js$/,
parser: { system: true },
},
{
test: /.(css|scss)$/,
use: ['to-string-loader', 'css-loader', 'sass-loader']
},
{
test: /.html$/,
loader: 'html-loader',
exclude: [root('src/index.html')],
},
];

const instrumentLoader = {
test: /.(js|ts)$/,
use: {
loader: 'babel-loader',
options: {
plugins: ['babel-plugin-istanbul']
}
},
enforce: 'post',
include: path.join(__dirname, '../..', 'src'),
exclude: [/.(e2e|spec).ts$/, /node_modules/, /(ngfactory|ngstyle).js/],
};

if (CODE_COVERAGE === 'true') loaders.push(instrumentLoader);

const webpackOptions = {
resolve: {
extensions: ['.ts', '.js']
},
module: {
rules: loaders
}
}

const options = {
webpackOptions
}

module.exports = wp(options)`

i know it is not part of cypress and even though i tried to set publicPath in webpackOptions not helping..

{ output:{ publicPath:'' } }
is there any suggestions please assist me?

[hogvarce]

same problem when switching to webpack 5

cypress/plugins/index.js
///
///
// @ts-check
const webpackPreprocessor = require('cypress-webpack-preprocessor-v5')
/**

• @type {Cypress.PluginConfig}
  */
  module.exports = (on) => {
  // find the Webpack config used by react-scripts
  const options = {
  webpackOptions: require('../../webpack.config.js'),
  watchOptions: {},
  }

on('file:preprocessor', webpackPreprocessor(options))
}

webpack.config.js

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const { CleanWebpackPlugin } = require('clean-webpack-plugin');
const { merge } = require('webpack-merge');

const TARGET = process.env.npm_lifecycle_event;

const common = {
entry: {
main: path.resolve(__dirname, './src/index.tsx'),
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].bundle.js',
},
plugins: [
new CleanWebpackPlugin(),
new HtmlWebpackPlugin({
title: 'WINK-CMS',
template: path.join(__dirname, 'src', 'template.html'), // шаблон
filename: 'index.html', // название выходного файла
}),
new MiniCssExtractPlugin({
filename: 'style-[hash].css',
}),
],
module: {
rules: [
{
test: /.js$/,
exclude: /node_modules/,
use: ['babel-loader'],
},
{
test: /.ts(x?)$/,
exclude: /node_modules/,
use: ['babel-loader'],
},
{
test: /.(png|jpe?g|gif)(?.*)?$/,
loader: 'url-loader',
options: {
limit: 10000,
name: './img/[name].[hash:7].[ext]',
},
},
{
test: /.svg$/,
use: ['@svgr/webpack'],
},
{
test: /.(woff|woff2|eot|ttf)(?v=\d+.\d+.\d+)?$/,
use: [
{
loader: 'url-loader',
options: {
limit: 10000,
name: './fonts/[name].[ext]',
},
},
],
},
{
test: /.(sa|sc|c)ss$/,
use: [
'style-loader',
'css-loader',
'sass-loader'
]
},
],
},
resolve: {
extensions: ['.tsx', '.ts', '.js', '.css', '.scss'],
modules: [
path.join(__dirname, 'src'),
'node_modules',
],
alias: {
react: path.join(__dirname, 'node_modules', 'react'),
},
}
};

const start = {
mode: 'development',
devServer: {
hot: true,
port: 9000,
historyApiFallback: {
index: '/'
}
}
};

switch (TARGET) {
default:
module.exports = merge(common, start);
}

i need help, please)

[reintroducing]

@dmtrKovalenko It looks like there may be a fix for this according to #14592 but that PR came after cypress-webpack-preprocessor-v5 was published. Is there any way you can add it to the v5 release so that we can solve a lot of these issues for those of us experiencing this on webpack 5?

[alexsegura]

On my side this seems to be happening when using Webpack 5's Asset Modules. I'm using Webpack Encore to generate the Webpack config, and it uses Asset Modules.

I have a rule like this, which is causing the problem:

{
  test: /\.(png|jpg|jpeg|gif|ico|svg|webp)$/,
  oneOf: [
    { resourceQuery: /copy-files-loader/, type: 'javascript/auto' },
    { type: 'asset/resource', generator: [Object], parser: {} }
  ]
}

When I replace it by a rule with url-loader, it works

{
  test: /\.(png|jpg|jpeg|gif|ico|svg|webp)$/i,
  use: [ { loader: 'url-loader' } ]
}

[brunojppb]

I had a similar issue. Since Webpack 5 doesn't polyfill node modules out-of-the-box anymore, I had to use the node-polyfill-webpack-plugin.

npm install --save-dev node-polyfill-webpack-plugin

And on your cypress on:file:preprocessor you can add it like this:

const preprocessor = require('cypress-webpack-preprocessor-v5')
const NodePolyfillPlugin = require('node-polyfill-webpack-plugin')

module.exports = (on) => {
  on('file:preprocessor', preprocessor({
      webpackOptions: {
        plugins: [ new NodePolyfillPlugin() ],
      },
    })
  )
}

[robbienohra]

Is there anything, in particular, blocking this at the moment?

It seems unacceptable for cypress to be this behind in formally supporting webpack 5.

[lmiller1990]

There is no technical blocker from what I can see. I will look into supporting Webpack 5 in webpack preprocessor.

[robbienohra]

@lmiller1990 fabulous! Thanks!

[inspiraller]

I just had too many problems with webpack 5 using either @cypress/webpack-preprocessor or cypress-webpack-preprocessor-v5 and so I instead have used @cypress/browserify-preprocessor.

It suits my purpose and I have full coverage support now with istanbul, nyc, typescript and cucumber.
While this example uses cucumber the same logic can be applied without:
badeball/cypress-cucumber-preprocessor#390

[lmiller1990]

Mid term, the goal will be @cypress/webpack-preprocessor@6, (current we are on v5), that will support webpack 5 and provide good defaults to make installation and usage as easy as possible.

To get something done in the short term, I basically migrated to changes from cypress-webpack-preprocessor-v5 into the @cypress/webpack-preprocessor. The draft PR is here. We can make this a minor release, so 5.8.0 (current is 5.7.0).

As for testing with a complex webpack 5 based app - this was the challenge. You can see the PR description for more info, but basically upgrading the main Cypress repo to use webpack 5 is quite a bit of work. I tested some of the sub projects and they compiled okay - around 95% of tests passed. I'll keep working on this, but it won't block the minor patch mentioned above.

Once this is released, the main problems that people will encounter are:

1. webpack 5 deprecated support for auto polyfilling node.js modules. You can see the above comment for a recommendation. There is lots of other info out there on how to work around this.
2. the publicPath problem described a few posts above. The main thing you need to do is configure a publicPath. There is some (basic) info in the webpack docs.

I'll post again once this patch is released. Then, if people are still having problems, I can look into specific reproductions.

[am-a]

Mid term, the goal will be @cypress/webpack-preprocessor@6, (current we are on v5), that will support webpack 5 and provide good defaults to make installation and usage as easy as possible.

To get something done in the short term, I basically migrated to changes from cypress-webpack-preprocessor-v5 into the @cypress/webpack-preprocessor. The draft PR is here. We can make this a minor release, so 5.8.0 (current is 5.7.0).

As for testing with a complex webpack 5 based app - this was the challenge. You can see the PR description for more info, but basically upgrading the main Cypress repo to use webpack 5 is quite a bit of work. I tested some of the sub projects and they compiled okay - around 95% of tests passed. I'll keep working on this, but it won't block the minor patch mentioned above.

Once this is released, the main problems that people will encounter are:

1. webpack 5 deprecated support for auto polyfilling node.js modules. You can see the above comment for a recommendation. There is lots of other info out there on how to work around this.
2. the publicPath problem described a few posts above. The main thing you need to do is configure a publicPath. There is some (basic) info in the webpack docs.

I'll post again once this patch is released. Then, if people are still having problems, I can look into specific reproductions.

Looks like the pre-processor doesn't support passing in the publicPath to output since it assigns over it here:

cypress/npm/webpack-preprocessor/index.ts

Lines 195 to 208 in da3e49b

	const webpackOptions: webpack.Configuration = _
	.chain(options.webpackOptions)
	.defaultTo(defaultWebpackOptions)
	.defaults({
	mode: defaultWebpackOptions.mode,
	})
	.assign({
	// we need to set entry and output
	entry,
	output: {
	path: path.dirname(outputPath),
	filename: path.basename(outputPath),
	},
	})

)

somebody opened a PR that would fix this but for whatever reason it was closed without being accepted: #14599

If anybody needs a hacky workaround for now I'm using:

  const webpackOptions = require('../../webpack/webpack.config.base.js').default; // ES6 module import, adjust as required
  const publicPath = 'http://localhost:3001/';
  let outputOptions = {};

  Object.defineProperty(webpackOptions, 'output', {
    get: () => {
      return { ...outputOptions, publicPath };
    },
    set: function (x) {
      outputOptions = x;
    },
  });

  on('file:preprocessor', webpack({ webpackOptions  }));

[lmiller1990]

This will be out in the next release (within 2 weeks).

[am-a]

This will be out in the next release (within 2 weeks).

@lmiller1990 - Are you referring to: https://github.com/cypress-io/cypress/pull/8929/files? I'm not sure it would address the publicPath issue

[lmiller1990]

I believe I was thinking about this one at the time: #15611 which fixes a bug where using Webpack 5 causes Cypress to hang. You can use Webpack 5 - but we still have some issues, apparently (publicPath).

I am not sure why #14599 was closed. If need this lets make a new PR with this feature and get it merged. Anything in the npm directory going out via semantic release, so if someone wants to fork from master, make the change, and make a PR against master, it'll go out as soon as it's merged.

I can look into this early next week if no-one beats me to it.

[brianorwhatever]

This is still a problem and this issue should be reopened. This workaround is the only way to get this to work..
#8900 (comment)

[lmiller1990]

I believe the original issue was solved. What problem are you seeing exactly? I am using Cypress with a webpack 5 project and it's working fine for me. Can you describe your problem (or provide a reproduction)?

It might be worth opening a new issue. Webpack's ecosystem is huge. It might be best to tackle the outstanding issues separately rather than re-opening very generic issue.

[brianorwhatever]

Just didn't wanna open an issue that'll get lost in the other 1.8k open issues..
Have opened this issue #18748

[Moranilt]

I have the same issue right now for webpack 5.

[lmiller1990]

I'm not sure why the other PR was closed (author closed himself), if anyone would like to make a PR with a fix I could give it a review, test, and get it merged. It looks like there's enough info in this thread to be able to make a PR fixing this issue.

[gkadillak-lyra]

Did this ever get included in a release version? I don't see this issue number in the releases. I expected it to be in v6.8.0, but that version was still throwing the same error for me.

[lmiller1990]

I think some patches were merged but the webpack support seems to have some issues still. There is a variety of things in this issue, can you make a new one with your specific reproduction? That would greatly help with debugging - there's a bit too much info here to make it clear which problem(s) are still ongoing for what configurations.