BaseOutputProcessor doesn't compatible with Webpack

[zentby]

When working with webpack and its cypress plugin, the default webpack has target: "web", which doesn't support the native require. Thus throw exceptions:

Oops...we found an error preparing this test file:

  cypress/support/index.js

The error was:

Error: Webpack Compilation Error
./node_modules/cypress-terminal-report/src/outputProcessor/BaseOutputProcessor.js
Module not found: Error: Can't resolve 'fs' in './node_modules/cypress-terminal-report/src/outputProcessor'
resolve 'fs' in './node_modules/cypress-terminal-report/src/outputProcessor'
  Parsed request is a module
...
...
 @ ./node_modules/cypress-terminal-report/src/outputProcessor/BaseOutputProcessor.js 1:11-24
 @ ./node_modules/cypress-terminal-report/src/outputProcessor/CustomOutputProcessor.js
 @ ./node_modules/cypress-terminal-report/src/installLogsPrinter.js
 @ ./node_modules/cypress-terminal-report/index.js
 @ ./cypress/support/index.js
 @ multi ./cypress/support/index.js

webpack.config

module.exports = {
    resolve: {
        extensions: ['.ts', '.js']
    },
    module: {
        rules: [
            {
                test: /\.ts$/,
                exclude: [/node_modules/],
                use: [
                    {
                        loader: 'ts-loader',
                        options: {
                            transpileOnly: true
                        }
                    }
                ]
            }
        ]
    }
};

Tried to change the target with target: "node" but it introduce new problems. Downgrade to v1.2.1 solved the problem.

Please consider opt the default processor out of loading from the default config.

[archfz]

You should not compile the plugins.js and support.js of cypress. Since you are using webpack only to transpile typescript you could remove js from the extensions and that might resolve it. Or otherwise set ignore pattern to not include this plugin into compilation.

Node js require is native and core functionality of node.js modules. There is nothing we can do about this.

[archfz]

Also please note that webpack gives error here for the fs module require. And since that is a native embedded module it doesn't actually have js code that is why its failing.

The support.js (in your case support/index.js) is meant for node side loading on cypress. It will not be loaded in the browser. This file is exactly meant by cypress for usage of modules like os, fs and any other low level node api.

[zentby]

Thanks for quick responding.

I agreed that plugins/index.js is used by cypress prior to run tests. However, the support/index.js is not. It is supposed to be running along with the tests.

Looking at the cypress docs:

supportFile | cypress/support/index.js | Path to file to load before test files load. This file is compiled and bundled. (Pass false to disable)

The folder is used for support code while running the tests.

Also, the .js cannot be stripped from the webpack config because the packing needs to resolve libs of .js files.

[archfz]

I looked into this a little bit closer. Sorry I actually mixed up the support file with the plugins file.

Indeed this is an issue because this plugins support and plugin install both are loaded through the same index.js file. Thus the fs require ends up in the support.js as well.

This will require a breaking change to improve on our side. Please still consider ignoring the support.js from compilation if that works.

[zentby]

I tried to exclude the support.js file but it would make everything fail.

I'm wondering before a proper fix/feature to address this, is it easy to add a new config field to not load that file at all? So that it at least won't break the projects with webpack.

[archfz]

Actually you can fix this for now by requiring the specific files rather then the index in plugins and support. ex require('cypress-terminal-report/src/installLogsCollector.js'). Take a look in index.js.

[sgronblo]

I had the same problem. I was able to get the plugin to work by installing the setup functions directly as @archfz suggested.

Thank you very much for making this plugin and for providing a workaround for this issue!

[archfz]

Released in 1.4.0