cypress-io / cypress-webpack-preprocessor Goto Github PK

View Code? Open in Web Editor NEW

93.0 20.0 22.0 1.66 MB

Cypress preprocessor for bundling JavaScript via webpack

cypress cypress-io plugin webpack cypress-preprocessor

cypress-webpack-preprocessor's Introduction

Cypress Webpack Preprocessor

Cypress preprocessor for bundling JavaScript via webpack

🚚 This repo has been moved

`@cypress/webpack-preprocessor` now lives in the main Cypress monorepo

cypress-webpack-preprocessor's People

Contributors

Stargazers

Watchers

cypress-webpack-preprocessor's Issues

Sources maps are not generated for typescript files

Operating System: Ubuntu
Cypress Version: 4.1.0
Browser Version: Chrome 80

Is this a Feature or Bug?

Bug

Current behavior:

No source maps are generated for typescript files.

Desired behavior:

Source maps should be available for test files.

How to reproduce:

Clone https://github.com/cypress-io/cypress-example-recipes
run npm install
run cd examples/preprocessors__typescript-webpack
uncomment debugger in cypress/integration/spec.ts
run npx cypress open
open spec.ts
open devtools
rerun tests
devtools show transpiled file

Additional Info (images, stack traces, etc)

It seems that webpack does not generate the source maps when the the extension of the output file is .ts. Js files in the same project have source maps generated.

Output bundling timings

To better understand where we spend time, need to print how long each bundle takes, so we can easily debug performance problems

Headless + Typescript

Is Cypress capable of running headlessly if the codebase is Typescript?

Using webpack-preprocessor, Module not found: Error

After experiencing this, and hearing people using quasar with cypress successfully using the webpack-preprocessor I tried to set that up. I get this error now (for every page/ component, here just showing one):

  Error: ./src/router/routes.js
  Module not found: Error: Can't resolve 'components/Favorites' in '/home/usr/y1  /src/router'
  resolve 'components/Favorites' in '/home/usr/y1/src/router'
    Parsed request is a module
    using description file: /home/usr/y1/package.json (relative path: ./src/rout  er)
      Field 'browser' doesn't contain a valid alias configuration
      resolve as module
        /home/usr/y1/src/router/node_modules doesn't exist or is not a directory        /home/usr/y1/src/node_modules doesn't exist or is not a directory
        /home/usr/node_modules doesn't exist or is not a directory
        /home/node_modules doesn't exist or is not a directory
        /node_modules doesn't exist or is not a directory
        looking for modules in /home/usr/y1/node_modules
          using description file: /home/usr/y1/package.json (relative path: ./no  de_modules)
            Field 'browser' doesn't contain a valid alias configuration
            using description file: /home/usr/y1/package.json (relative path: ./  node_modules/components/Favorites)
              no extension
                Field 'browser' doesn't contain a valid alias configuration
                /home/usr/y1/node_modules/components/Favorites doesn't exist
              .wasm
                Field 'browser' doesn't contain a valid alias configuration
                /home/usr/y1/node_modules/components/Favorites.wasm doesn't exis  t
              .mjs
                Field 'browser' doesn't contain a valid alias configuration
                /home/usr/y1/node_modules/components/Favorites.mjs doesn't exist              .js
                Field 'browser' doesn't contain a valid alias configuration
                /home/usr/y1/node_modules/components/Favorites.js doesn't exist
              .json
                Field 'browser' doesn't contain a valid alias configuration
                /home/usr/y1/node_modules/components/Favorites.json doesn't exis  t
              as directory
                /home/usr/y1/node_modules/components/Favorites doesn't exist
  [/home/usr/y1/src/router/node_modules]
  [/home/usr/y1/src/node_modules]
  [/home/usr/node_modules]
  [/home/node_modules]
  [/node_modules]
  [/home/usr/y1/node_modules/components/Favorites]
  [/home/usr/y1/node_modules/components/Favorites.wasm]
  [/home/usr/y1/node_modules/components/Favorites.mjs]
  [/home/usr/y1/node_modules/components/Favorites.js]
  [/home/usr/y1/node_modules/components/Favorites.json]
   @ ./src/router/routes.js 66:13-43
   @ ./src/router/index.js
   @ ./src/api.js
   @ ./tests/e2e/integration/home_page_spec.js
  ./src/router/routes.js
  Module not found: Error: Can't resolve 'components/Home' in '/home/usr/y1/src/  router'
  resolve 'components/Home' in '/home/usr/y1/src/router'
    Parsed request is a module
[etc.]

.babelrc:

{
  "presets": [
    [ "env", {"modules": false} ],
    "stage-2"
  ],
  "plugins": ["transform-runtime"],
  "comments": false,
  "env": {
    "test": {
      "presets": [
        [
          "env",
          {
            "targets": {
              "node": "current"
            }
          }
        ]
      ],
      "plugins": [
        [
          "module-resolver",
          {
            "root": [
              "./src"
            ],
            "alias": {
              "quasar": "quasar-framework/dist/quasar.mat.esm.js",
              "^vue$": "vue/dist/vue.common.js"
            }
          }
        ]
      ]
    }
  }
}

cypress/plugins/index.js:

const webpack = require('@cypress/webpack-preprocessor')

// see: https://github.com/quasarframework/quasar-cli/issues/83#issuecomment-380741985
const mywebpackoptions = {
  module: {
    rules: [
      {
        test: /\.(js|vue)$/,
        loader: 'babel-loader',
        enforce: 'pre',
        exclude: /(node_modules|quasar)/
      }
    ]
  }
}

// `on` is used to hook into various events Cypress emits
// `config` is the resolved Cypress config
module.exports = (on) => {
  const options = {
    // send in the options from your webpack.config.js, so it works the same
    // as your app's code
    webpackOptions: mywebpackoptions,
    watchOptions: {}
  }

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

The actual component is in /home/usr/y1/src/components/Favorites.vue but compiler looks in node_modules folders only it seems.

Support async webpack config

Operating System: N/A
Cypress Version: N/A
Browser Version: N/A

Is this a Feature or Bug?

Feature (or a bug since this is supported by webpack since v2)

Current behavior:

You can't export a Promise which resolves to a webpack config object in webpack.config.js

Desired behavior:

https://webpack.js.org/configuration/configuration-types/#exporting-a-promise

How to reproduce:

Export a Promise.

Add TypeScript example

Following https://webpack.js.org/guides/typescript/

Requires babel-loader and @babel/preset-env even if you don't use them

Operating System: Windows 10
Cypress Version: 3.1.1
Browser Version: N/A

Is this a Feature or Bug?

Bug

Current behavior:

When I try to run Cypress with TypeScript, without babel-loader or `@babel/preset-env installed, I get the following error message.

The plugins file is missing or invalid.

Your pluginsFile is set to 'D:\wamp64\www\collapo\cypress\plugins\index.js', but either the file is missing, it contains a syntax error, or threw an error when required. The pluginsFile must be a .js or .coffee file.

Please fix this, or set 'pluginsFile' to 'false' if a plugins file is not necessary for your project.

The following error was thrown:
Error: Cannot find module 'babel-loader'
at Function.Module._resolveFilename (module.js:485:15)
at Function.resolve (internal/module.js:18:19)
at Object. (D:\wamp64\www\collapo\node_modules\@cypress\webpack-preprocessor\index.js:20:31)
at Object. (D:\wamp64\www\collapo\node_modules\@cypress\webpack-preprocessor\index.js:181:3)
at Module._compile (module.js:569:30)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:503:32)
at tryModuleLoad (module.js:466:12)
at Function.Module._load (module.js:458:3)
at Module.require (module.js:513:17)
at require (internal/module.js:11:18)
at Object. (D:\wamp64\www\collapo\cypress\plugins\index.js:2:12)
at Object. (D:\wamp64\www\collapo\cypress\plugins\index.js:11:3)
at Module._compile (module.js:569:30)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:503:32)
at tryModuleLoad (module.js:466:12)
at Function.Module._load (module.js:458:3)
at Module.require (module.js:513:17)
at require (internal/module.js:11:18)
at module.exports (C:\Users\Jake\AppData\Local\Cypress\Cache\3.1.1\Cypress\resources\app\packages\server\lib\plugins\child\run_plugins.js:118:15)
at Object. (C:\Users\Jake\AppData\Local\Cypress\Cache\3.1.1\Cypress\resources\app\packages\server\lib\plugins\child\index.js:14:25)

Desired behavior:

If I comment out the defaultConfig loader code as I've done below, Cypress works with my current set of installed packages. Ideally, I think the default options should only run require.resolve if the webpackOptions.module.rules reference doesn't change after merging with the optional override done via cypress\plugins\index.js.

// by default, we transform JavaScript (up to anything at stage-4) and JSX
const defaultOptions = {
  webpackOptions: {
    module: {
      rules: [
        {
          test: /\.jsx?$/,
          exclude: [/node_modules/],
          use: [
            /*{
              loader: require.resolve('babel-loader'),
              options: {
                presets: require.resolve('@babel/preset-env'),
              },
            },*/
          ],
        },
      ],
    },
  },
  watchOptions: {},
}

How to reproduce:

Essentially use the files / setup from Typescript with Webpack and have the same packages that I have installed below.

{
  "name": "name",
  "version": "0.1.0",
  "license": "MIT",
  "private": true,
  "keywords": [
    "typescript",
  ],
  "scripts": {
    "cypress:run": "cypress run",
    "cypress:open": "cypress open",
    "tslint": "tslint --project ./tsconfig.json"
  },
  "devDependencies": {
    "@cypress/webpack-preprocessor": "^4.0.0",
    "cypress": "^3.1.1",
    "ts-loader": "^5.3.0",
    "typescript": "^3.1.6",
    "webpack": "^4.25.1",
    "webpack-cli": "^3.1.2",
    "webpack-dev-server": "^3.1.10"
  }
}

Consider disable optimization so debugger statements are not stripped

Cypress Version: 3.1.0
Package Version: 3.0.0

Is this a Feature or Bug?

Not expected behavior

Current behavior:

debugger statements are stripped from tests with default settings of cypress-webpack-preprocessor

Desired behavior:

Should not be stipped or at least it should be very well documented

How to reproduce:

Cypress.on("fail", (err, runnable) => {
  console.log("I'm here!!!")
  debugger // eslint-disable-line no-debugger
  return err
})

is compiled to

Cypress.on("fail", function(e, t) {
  return console.log("I'm here!!!"),
  e
}),

adding

const options = webpack.defaultOptions
  options.webpackOptions.optimization = { minimize: false } // THIS!
  on("file:preprocessor", webpack(options))

will not strip the debugger

I can submit PR if you will agree

Crashes when preprocessing 24 Typescript tests (but sometimes works)

Operating System: OS X 10.14.6
Cypress Version: 4.5.0
Browser Version: Chrome 81.0.4044.122
Node Version: 14.1.0
"@cypress/webpack-preprocessor": "^5.1.2",
"ts-loader": "^7.0.1",
"typescript": "^3.8.3",
"webpack": "^4.43.0"

Current behavior:

npx cypress open
Click "Run all specs"

Observe a lot of output as exampled below in [1] streaming in the terminal cypress was launched from. Also observe a couple of mentions of

(node:90085) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 close listeners added to [EventEmitter]. Use emitter.setMaxListeners() to increase limit

Process crashes with

write EPIPE
GET /__cypress/iframes/__all 200 16.952 ms - -
Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
    at ServerResponse.setHeader (_http_outgoing.js:485:11)
    at ServerResponse.header (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/express/lib/response.js:767:10)
    at ServerResponse.send (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/express/lib/response.js:170:12)
    at /Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/lib/controllers/spec.js:37:20
    at tryCatcher (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/promise.js:547:31)
    at Promise._settlePromise (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/promise.js:604:18)
    at Promise._settlePromise0 (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/promise.js:649:10)
    at Promise._settlePromises (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/promise.js:725:18)
    at _drainQueueStep (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/async.js:93:12)
    at _drainQueue (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/async.js:102:5)
    at Immediate.Async.drainQueues [as _onImmediate] (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/async.js:15:14)
    at processImmediate (internal/timers.js:439:21) {
  code: 'ERR_HTTP_HEADERS_SENT'
}
Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
    at ServerResponse.setHeader (_http_outgoing.js:485:11)
    at ServerResponse.header (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/express/lib/response.js:767:10)
    at ServerResponse.send (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/express/lib/response.js:170:12)
    at /Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/lib/controllers/spec.js:37:20
    at tryCatcher (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/promise.js:547:31)
    at Promise._settlePromise (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/promise.js:604:18)
    at Promise._settlePromise0 (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/promise.js:649:10)
    at Promise._settlePromises (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/promise.js:725:18)
    at _drainQueueStep (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/async.js:93:12)
    at _drainQueue (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/async.js:102:5)
    at Immediate.Async.drainQueues [as _onImmediate] (/Users/mikehogan/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/async.js:15:14)
    at processImmediate (internal/timers.js:439:21)

[1] Here is what I was referring to as a lot of output streaming:

GET /__cypress/iframes/__all 200 8.021 ms - -
GET /__cypress/tests?p=cypress/support/index.js-279 200 107.993 ms - -
GET /__cypress/tests?p=cypress/integration/can_create_new_types_when_creating_lookup_properties.ts-722 200 94.992 ms - -
GET /__cypress/tests?p=cypress/integration/auto_number_ids.ts-487 200 103.373 ms - -
GET /__cypress/tests?p=cypress/integration/can_delete_relationships.ts-207 200 94.464 ms - -
GET /__cypress/tests?p=cypress/integration/can_change_property_type.ts-580 200 99.629 ms - -
GET /__cypress/tests?p=cypress/integration/booking_form_example.ts-520 200 101.593 ms - -
GET /__cypress/tests?p=cypress/integration/can_reorder_properties.ts-887 200 171.030 ms - -
GET /__cypress/tests?p=cypress/integration/focus_when_adding_new_row.ts-281 200 77.302 ms - -
GET /__cypress/tests?p=cypress/integration/can_delete_rows.ts-996 200 309.110 ms - -
GET /__cypress/tests?p=cypress/integration/cross_linking_of_models.ts-054 200 170.616 ms - -
GET /__cypress/tests?p=cypress/integration/keyboard_shortcuts.ts-193 200 151.043 ms - -
GET /__cypress/tests?p=cypress/integration/model_edits_must_preserve_model_integrity.ts-101 200 146.098 ms - -
GET /__cypress/tests?p=cypress/integration/formula_properties.ts-123 200 237.230 ms - -
GET /__cypress/tests?p=cypress/integration/model_tagging_and_filtering.ts-838 200 133.924 ms - -
GET /__cypress/tests?p=cypress/integration/properties_can_link_to_other_models.ts-132 200 81.594 ms - -
GET /__cypress/tests?p=cypress/integration/selectors.ts-733 200 507.636 ms - -
GET /__cypress/tests?p=cypress/integration/spreadsheet_like_data_entry_submission_and_navigation.ts-606 200 426.558 ms - -
GET /__cypress/tests?p=cypress/integration/supporting_airtable_tables.ts-890 200 70.363 ms - -
GET /__cypress/tests?p=cypress/integration/supporting_colour.ts-098 200 47.577 ms - -
GET /__cypress/tests?p=cypress/integration/reporting-to-other-models.ts-382 - - ms - -
GET /__cypress/tests?p=cypress/integration/prompted_values_in_text_inputs.ts-833 200 4124.871 ms - -
GET /__cypress/tests?p=cypress/integration/data_entry_formats.ts-809 - - ms - -
GET /__cypress/tests?p=cypress/integration/multiple_instances_of_same_value_type.ts-148 - - ms - -
GET /__cypress/tests?p=cypress/integration/what_signature_requires.ts-276 - - ms - -
GET /__cypress/tests?p=cypress/integration/what_tom_requires.ts-603 200 2558.794 ms - -

If I do the above 4 or 5 or 6 times, sometimes all the tests come up in the GUI and I can run them all. We're talking about 24 tests, none of which are especially long or complex.

Desired behavior:

Tests preprocess and run in the GUI

How to reproduce:

As per above

Additional Info (images, stack traces, etc)

Here is my plugins/index.js:

    const wp = require('@cypress/webpack-preprocessor')
    
    module.exports = (on, config) => {
        const options = {
            webpackOptions: {
                resolve: {
                    extensions: [".ts", ".tsx", ".mjs",".js"]
                },
                module: {
                    rules: [
                        {
                            test: /\.tsx?$/,
                            loader: "ts-loader",
                            options: { transpileOnly: true }
                        }
                    ]
                }
            },
        }
        on('file:preprocessor', wp(options))
    }

Here is my tsconfig.json:

    {
      "compilerOptions": {
        "strict": true,
        "baseUrl": "../node_modules",
        "esModuleInterop": true,
        "target": "es5",
        "lib": ["es5", "dom"],
        "types": ["cypress"]
      },
      "include": [
        "**/*.ts",
        "../src/**/*.ts"
      ]
    }

This is my cypress.json:

{
  "nodeVersion": "system",
  "video": false,
  "numTestsKeptInMemory": 1
}

Don't require Node 8

Node 6 should work fine with this plugin and it is LTS for another year. Yarn forces the engine to match. Forcing the engine to version 8 means that you can't use cypress with the preprocessor and webpack 4 unless you're on Node 8.

This seems unnecessary.

Module not found: Can't resolve

Operating System: Win 7 / 10
Cypress Version: latest
Browser Version: latest

Is this a Feature or Bug?

Bug

Current behavior:

./cypress/integration/simple/spec.ts
Module not found: Error: Can't resolve './test' in 'C:\Users\...\cypress\integration\simple'
resolve './test' in 'C:\Users\...\cypress\integration\simple'
  using description file: C:\Users\...\package.json (relative path: ./cypress/integration/simple)
    Field 'browser' doesn't contain a valid alias configuration
    using description file: C:\Users\...\package.json (relative path: ./cypress/integration/simple/test)
      no extension
        Field 'browser' doesn't contain a valid alias configuration
        C:\Users\...\cypress\integration\simple\test doesn't exist
      .wasm
        Field 'browser' doesn't contain a valid alias configuration
        C:\Users\...\cypress\integration\simple\test.wasm doesn't exist
      .mjs
        Field 'browser' doesn't contain a valid alias configuration
        C:\Users\...\cypress\integration\simple\test.mjs doesn't exist
      .js
        Field 'browser' doesn't contain a valid alias configuration
        C:\Users\...\cypress\integration\simple\test.js doesn't exist
      .json
        Field 'browser' doesn't contain a valid alias configuration
        C:\Users\...\cypress\integration\simple\test.json doesn't exist
      as directory
        C:\Users\...\cypress\integration\simple\test doesn't exist
[C:\Users\...\cypress\integration\simple\test]
[C:\Users\...\cypress\integration\simple\test.wasm]
[C:\Users\...\cypress\integration\simple\test.mjs]
[C:\Users\...\cypress\integration\simple\test.js]
[C:\Users\...\cypress\integration\simple\test.json]
 @ ./cypress/integration/simple/spec.ts 3:0-30 8:32-36

Desired behavior:

It should work with imports.

How to reproduce:

It is so simple :)

Additional Info (images, stack traces, etc)

/// <reference types="cypress" />
import expect from "expect";
import { Test } from "./test";
describe('My First Test', function () {
  it('get Google site title"', function () {
    cy.visit('https://www.google.com/');

    cy.title().should('eq', new Test().message)
  })
})

export class Test {
  message = "Google";
}

Fix issues with PR #38

No progress feedback while preprocessor is running

Operating System: MacOS, Ubuntu
Cypress Version: 3.1.5
Browser Version: Chrome 72

Is this a Feature or Bug?

Feature

Current behavior:

When preprocessor is running, cypress window boots and shows a blank output while preprocessor is running. If you have a slow compilation process e.g. typescript, it can be confusing waiting for ~20 seconds while nothing appears to happen

Desired behavior:

Indication of the progress of the plugin, or even just a notice that the preprocessor is running, standby...

How to reproduce:

Use the preprocessor plugin, make it wait for an extended period of time

Purpose of this preprocessor?

I'm trying to get Cypress integrated into an existing project and I've wired up this preprocessor up and I'm not sure what it is that it is doing or why I should use it.

I was thinking that maybe, since it allows me to pass in my existing webpack config, that it would launch the development server and all that for me, but alas it doesn't. Then I was thinking that maybe it had something to do with restarting the tests when a file is modified, but that doesn't appear to be the case either--the webpack development server does its own reload of the page inside Cypress but does not cause the tests to re-run.

What am I missing?

Here's my plugins/index.js:

require('babel-register')

const WebpackPreprocessor = require('@cypress/webpack-preprocessor')
const WebpackConfig = require('../../webpack.config.babel')

module.exports = (on, config) => {
  on('file:preprocessor', WebpackPreprocessor({
    webpackOptions: WebpackConfig,
  }))
}

I'm not sure that posting my entire webpack.config would be useful here.

Finally, is there any way to get Cypress to work in conjunction with my existing webpack development server configuration?

Error: Excepted condition but got [object Object]

Operating System: macOS 10.12.1
Cypress Version: 1.4.1
Browser Version: N/A

Is this a Feature or Bug?

A bug

Current behavior:

Custom webpack config in plugins/index.js:

Error: Excepted condition but got [object Object] in {
  "test": {},
  "include": "undefined",
  "exclude": [
    {}
  ]
}

Desired behavior:

No error

How to reproduce:

Set up the following plugin file:

const webpack = require('@cypress/webpack-preprocessor')
 
module.exports = (on, config) => {
   // `on` is used to hook into various events Cypress emits
   // `config` is the resolved Cypress config
   const options = webpack.defaultOptions
   const rule = options.webpackOptions.module.rules[0]

   rule.use[0].options.presets.push('babel-preset-stage-0')
   on('file:preprocessor', webpack(options))
}

Additional Info (images, stack traces, etc)

SyntaxError: 'import' and 'export' may appear only with 'sourceType: module'

Operating System: Linux
Cypress Version: latest
Browser Version: latest

Is this a Feature or Bug?

BUG/Question

Current behavior:

I'm trying to create e2e tests with Cypress + Cucumber + Typescript + cypress/webpack-preprocessor
When step-definition file don't have imports/exports - everything works well
But when I'm trying to use PageObjects in TS, using export-import statement, then I got an error like 'import' and 'export' may appear only with 'sourceType: module'

I don't have the possibility to change imports and exports to require and module.export because in my current project I have a lot of PO's and I want to save 2 approaches in tests: default approach and BDD approach

Desired behavior:

Possibilities to use import and export

How to reproduce:

https://github.com/ludmilanesvitiy/cypress-cucumber-example/pull/1/files
In this PR you can see how to reproduce the issue
In the main repository all works well.

Additional Info (images, stack traces, etc)

Error in types

Operating System: N/A
Cypress Version: N/A
Browser Version: N/A

Is this a Feature or Bug?

Bug

Current behavior:

When using the types, we get this error:

  // Exports and export assignments are not permitted in module augmentations.
  export = _default;

Desired behavior:

No error

How to reproduce:

Import the types into your TS project and run tsc

Additional Info (images, stack traces, etc)

Related: #67

How can flow types be removed?

This is not a bug. I am wondering how to make the webpack preprocessor strip flow types. I have a project that uses flow and webpack. Cypress errors on the unrecognized flow syntax with Cypress version 3.1.0.

I looked into this comment on the main Cypress repo but that does not work.

I have also tried adding a Cypress plugin like this

const webpack = require('@cypress/webpack-preprocessor')

module.exports = (on) => {
  const options = webpack.defaultOptions
  options.webpackOptions.module.rules[0].use[0].options.presets.push('@babel/plugin-transform-flow-strip-types')

  console.log(options)
  on('file:preprocessor', webpack(options))
}

However it appears that Cypress trying to run code with the flow types in it.

Missing type for "defaultOptions"

We export the preprocessor function and attach "defaultOptions" property on it

// provide a clone of the default options, lazy-loading them
// so they aren't required unless the user utilizes them
Object.defineProperty(preprocessor, 'defaultOptions', {
  get () {
    debug('get default options')

    return {
      webpackOptions: getDefaultWebpackOptions(),
      watchOptions: {},
    }
  },
})

since it is missing from the type signature, it is easy to use it incorrectly cypress-io/cypress-react-unit-test#188

Syntax errors cause browser to close and error displayed in Desktop GUI

Operating System: MacOS
Cypress Version: 3.6.0
Browser Version: Any

Is this a Feature or Bug?

Bug

Current behavior:

While running a test, if you have a syntax error, the browser is closed and the error is displayed in the Desktop GUI.

Desired behavior:

The error should be displayed in the browser without it closing. Upon fixing the syntax error in the test file, the test should re-run without having to manually re-open the browser.

How to reproduce:

Run an error-free test file in Cypress
Edit the test file to include a syntax error and save it

Additional Info (images, stack traces, etc)

#26 describes the same behavior, but while using ts-loader. This issue occurs with the default configuration, whereas #26 may have additional issues caused by the ts-loader, so the solution to this issue may not fix #26.

Unable to import `Options` from types

Extracted from #67 (comment)

Operating System: N/A
Cypress Version: N/A
Browser Version: N/A

Is this a Feature or Bug?

Bug

Current behavior:

const webpack = require('@cypress/webpack-preprocessor');
// Error:
// Namespace '_default' has no exported member 'Options'
/** @type {webpack.Options} */
const options = {
  webpackOptions: {}
}

Desired behavior:

No error

How to reproduce:

See code above.

Additional Info (images, stack traces, etc)

no codeframe in cypress dev mode

it seems e.originalStack is no longer being serialized or something when cypress is in dev mode, so no code-frame is shown in run mode or open mode

Cypress 4.0.0

compilation errors do not cause browser to refesh spec

Is this a Feature or Bug?

bug

Current behavior:

upon compilation error, the browser does not reload automatically, and requires a manual refresh to see it

Desired behavior:

compilation errors should be displayed in the browser runner without having to manually reload the page

How to reproduce:

in this repo:

npx cypress open
[select compile-error.js]
[make a change + save compile-error.js]
[notice new syntax error is not reflected in browser gui until manual refresh]

Additional Info (images, stack traces, etc)

Webpack silently fails when user config defined code split chunks

Operating System: Windows 7 / Mac OS X Sierra
Cypress Version: 3.1.0
Browser Version: FF 62

Is this a Feature or Bug?

Bug

Current behavior:

When the user provides a webpack configuration that includes any sort of code splitting, i.e. with the optimization.splitChunks option, compilation silently fails and cypress says that the test file doesn't contain any tests.

Desired behavior:

The preprocessor should correctly transpile test files and tests should be run.

How to reproduce:

Will prodive repo asap.

Additional Info (images, stack traces, etc)

Related issues:

As far as I understand the source of this preprocessor plugin, the problem is that it's designed to work with exactly one bundle file.

A possible solution would be to make sure that any user-provided webpack config doesn't contain any code splitting config:

https://github.com/cypress-io/cypress-webpack-preprocessor/blob/master/index.js#L64-L65

before

// user can override the default options
let webpackOptions = Object.assign({}, defaultOptions.webpackOptions, options.webpackOptions)

after

// user can override the default options
const userWebpackOptions = options.webpackOptions
if (userWebpackOptions.optimization) {
  userWebpackOptions.runtimeChunk = undefined
  userWebpackOptions.splitChunks = undefined
}
let webpackOptions = Object.assign({}, defaultOptions.webpackOptions, options.webpackOptions)

Empty plugins file error

If the plugins file is empty, the error message is weird

You may need an appropriate loader to handle this file type.

Operating System: Win 7 / 10
Cypress Version: latest
Browser Version: latest

Is this a Feature or Bug?

Bug

Current behavior:

Desired behavior:

load any .ts files without a problem.

How to reproduce:

This is very simple ts file for getting Google title based on a ts class field.

Additional Info (images, stack traces, etc)

This is my code

/// <reference types="cypress" />
import expect from "expect";
describe('My First Test', function () {
  it('get Google site title"', function () {
    cy.visit('https://www.google.com/');

    cy.title().should('eq', new Test().message)
  })
})

export class Test {
  message = "Google"; /* (23:10)  */
}

Modules imported in support file are not visible through webpack

Current behavior:

Classes that are imported in the support file are loaded but not known to webpack.

Desired behavior:

Classes should be requireable through webpack.

How to reproduce:

Please use following minimal working example:
https://github.com/gabbersepp/cypress-missing-module

Additional Info (images, stack traces, etc)

First I want to explain our use case:
We have a system with several different brands. Each brand can have customized client behaviour. E.g. some brands do have buttons that others don't have.
To be able to test all brands within one cypress testsuite repo, we introduced an environment variable, called "Brand".
And if a brand needs some special behaviour, we create a new class that inherits from the base class and extends the behaviour to reflect the customized behaviour.

Simple example using Typescript (but that does not matter, the same occurs in JS, too.

export default class SaveLogic {
	...
	public clickSaveButton() {
		cy.get(".default-save-button").click();
	}
	...
}

//.....
export default class SaveLogicBrand1 extends SaveLogic {
	public clickSaveButton() {
		cy.get(".extra-save-button").click();
	}
}

Usage:

import SaveLogic from "...";
...
var saveLogic = DependencyResolver.resolve<SaveLogic>(SaveLogic);
saveLogic.clickSaveButton()
...

The DependencyResolver knows, based on a anotation of the base class, whether or not it must require the customized class (by naming convention it knows the path).
We use the __webpack_require__ function as used in the repo.

Using this approach we can use SaveLogic everywhere and have to write our test only once for all but are able to overwrite specific functionality. So we do not reference the brand classes anywhere in the tests.

To overcome the webpack behaviour to include only referenced files, we import all brand files in the cypress support file.

This works. If you execute the example in the repo, the assert expect(window.asd).to.equal("asd"); is green which means, that Module2.js have been loaded and the field window.asd has been set correctly.
But if we try to import that module, webpack does not know it.
See the attached image which shows all modules webpack knows.

Does anyone have a clue how to fix this? Currently our fix is to import the support file in all test suites.

Operating System: Windows 10
Cypress Version: 3.2.0
Browser Version: Chrome 73.0.x

Cannot load first config

Plugins file (valid file)

const webpackPreprocessor = require('@cypress/webpack-preprocessor')
module.exports = (register, config) => {
  register('on:spec:file:preprocessor', webpackPreprocessor(config))
}

Cypress preprocessor-refactor shows error message

Webpack 4 ts-loader issue

Operating System: Mac OS
Cypress Version: Latest
Browser Version: Latest

Is this a Feature or Bug? Bug

Current behavior:

I use Cypress with typescript and with library https://github.com/bahmutov/add-typescript-to-cypress. It uses @cypress/webpack-preprocessor and ts-loader to compile spec files written in typescript. After upgrading to webpack 4 and ts-loader 4 [Which doesn't support webpack 3 or webpack 2 ] I get Module build failed: TypeError: Cannot read property 'afterCompile' of undefined. This is due to @cypress/webpack-preprocessor using webpack 3 version as the dependency.

Desired behavior:

I have a working repo with a fix and running tests (its just one line update of webpack version )but would like to create PR. If you could let me know it would be of great help

How to reproduce:

Additional Info (images, stack traces, etc)

Webpack compilation error with defaultOptions

Operating System: MacOS 10.13.6
Cypress Version: 3.1.1 (cypress-webpack-preprocessor 4.0.0)
Browser Version: N/A
Other: react-scripts 2.0.4 (which provides webpack 4 and babel 7)

Is this a Feature or Bug?

Bug, fails to run cypress tests

Current behavior:

When using the defaultOptions for webpack the presets is set to a string, but babel validates this as an array:

Error: Webpack Compilation Error at assertArray (/node_modules/@babel/core/lib/config/validation/option-assertions.js:150:11) at assertPluginList (/node_modules/@babel/core/lib/config/validation/option-assertions.js:219:15) at Object.keys.forEach.key (/node_modules/@babel/core/lib/config/validation/options.js:107:5) at Array.forEach (<anonymous>) at validateNested (/node_modules/@babel/core/lib/config/validation/options.js:83:21) at validate (/node_modules/@babel/core/lib/config/validation/options.js:74:10) at loadPrivatePartialConfig (/node_modules/@babel/core/lib/config/partial.js:66:50) at Object.loadPartialConfig (/node_modules/@babel/core/lib/config/partial.js:110:18)

Desired behavior:

The presets should be set to an array in defaultOptions, my current workaround is to fix this in plugins/index.js:

const webpack = require('@cypress/webpack-preprocessor');

module.exports = (on) => {
    const options = webpack.defaultOptions;
    options.webpackOptions.module.rules[0].use[0].options.presets = [options.webpackOptions.module.rules[0].use[0].options.presets];
    on('file:preprocessor', webpack(options))
};

How to reproduce:

Add webpack-preprocessor as a dependency version 4.0.0, and use with CRA2 (create-react-app V2). CRA2 uses webpack 4.x and babel 7.x

Additional Info (images, stack traces, etc)

Commit where presets was changed from array to string:
22db72da03943f9e28237033935e1bf4d8dddf25

Crash with the error: `Multiple assets emit to the same filename`

Operating System: Debian Stretch
Cypress Version: 1.4.1
Browser Version: none

Is this a Feature or Bug?

Bug

Current behavior:

When I load my Webpack config as mentioned in this project's README, Webpack gives the following:

chunk manifest [entry]
open-app-cypress.js
Conflict: Multiple assets emit to the same filename open-app-cypress.js
Error: Conflict: Multiple assets emit to the same filename open-app-cypress.js

Desired behavior:

No error should be displayed

How to reproduce:

Pass in the webpack config passed by a project initialized with vue-cli to this plugin.

Additional Info (images, stack traces, etc)

open-app-cypress.js is the name of my sample test file.
It might be related to the fact that test files are processed twice?

Disabled semver support -> incompatible with create-react-app

A recent commit removed the hat prefixes (^) from many of the packages in package.json, preventing npm from discovering mutually compatible versions when installing packages. There may have been a valid reason for this, though no explanation was given so I can't be sure.

As it happens, this has caused this package to become incompatible with create-react-app, the most popular React boilerplate library, where you'll see this message after installing @cypress/webpack-preprocessor and running npm start in create-react-app:

There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.

The babylon-react-scripts package provided by Create React App requires a dependency:

  "babel-loader": "8.0.4"

Don't try to install it manually: your package manager does it automatically.
However, a different version of babel-loader was detected higher up in the tree:

  /Users/dominic.chambers/dev/monoweb/node_modules/babel-loader (version: 8.0.2)

Manually installing incompatible versions is known to cause hard-to-debug issues.

If prefer to ignore this check, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
That will permanently disable this message but you might encounter other issues.

To fix the dependency tree, try following the steps below in the exact order:

  1. Delete package-lock.json (not package.json!) and/or yarn.lock in your project folder.
  2. Delete node_modules in your project folder.
  3. Remove "babel-loader" from dependencies and/or devDependencies in the package.json file in your project folder.
  4. Run npm install or yarn, depending on the package manager you use.

In most cases, this should be enough to fix the problem.
If this has not helped, there are a few other things you can try:

  5. If you used npm, install yarn (http://yarnpkg.com/) and repeat the above steps with it instead.
     This may help because npm has known issues with package hoisting which may get resolved in future versions.

  6. Check if /Users/dominic.chambers/dev/monoweb/node_modules/babel-loader is outside your project directory.
     For example, you might have accidentally installed something in your home folder.

  7. Try running npm ls babel-loader in your project folder.
     This will tell you which other package (apart from the expected babylon-react-scripts) installed babel-loader.

If nothing else helps, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
That would permanently disable this preflight check in case you want to proceed anyway.

P.S. We know this message is long but please read the steps above :-) We hope you find them helpful!

Any chance the hat could be added back for babel-loader?

Usage with DllReferencePlugin ?

This is not a bug but maybe a new feature to implement. My React application is bundling by webpack but also split into two bundles thanks to DllReferencePlugin. Webpack produces a vendor bundle and my app bundle.
I'm wondering how should I configure cypress-webpack-preprocessor with this webpack configuration.

Any help will be greatly appreciated ?

DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead

Operating System: macOS High Sierra (10.13.6)
Cypress Version: 3.1.0
Browser Version:

Is this a Feature or Bug?

I found a DeprecationWarning .
Bug???

Current behavior:

It was found when the command was executed with the following settings.

package.json

{
...
  "scripts": {
    ...
    "test:e2e": "vue-cli-service test:e2e",
    ...
  },
...
}

$ yarn test:e2e --headless

stack trace when executed.

(node:6017) DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead
    at Object.handler (/Users/tsukachu/workspace/private/vue/livue/node_modules/@cypress/webpack-preprocessor/index.js:147:14)
    at invoke (/Users/tsukachu/Library/Caches/Cypress/3.1.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/child/run_plugins.js:16:16)
    at /Users/tsukachu/Library/Caches/Cypress/3.1.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/util.js:48:16
    at tryCatcher (/Users/tsukachu/Library/Caches/Cypress/3.1.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/release/util.js:16:23)
    at Function.Promise.attempt.Promise.try (/Users/tsukachu/Library/Caches/Cypress/3.1.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/bluebird/js/re
lease/method.js:39:29)
    at Object.wrapChildPromise (/Users/tsukachu/Library/Caches/Cypress/3.1.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/util.js:47:28)
    at Object.wrap (/Users/tsukachu/Library/Caches/Cypress/3.1.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/child/preprocessor.js:25:8)
    at execute (/Users/tsukachu/Library/Caches/Cypress/3.1.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/child/run_plugins.js:69:20)
    at EventEmitter.ipc.on (/Users/tsukachu/Library/Caches/Cypress/3.1.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/child/run_plugins.js:125:5)
    at emitThree (events.js:135:13)
    at EventEmitter.emit (events.js:216:7)
    at process.<anonymous> (/Users/tsukachu/Library/Caches/Cypress/3.1.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/util.js:25:29)
    at emitTwo (events.js:125:13)
    at process.emit (events.js:213:7)
    at emit (internal/child_process.js:768:12)
    at _combinedTickCallback (internal/process/next_tick.js:141:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)

ref: https://github.com/cypress-io/cypress-webpack-preprocessor/blob/master/package.json#L65

Desired behavior:

DeprecationWarning is not output.

How to reproduce:

Please refer to Current behavior

Additional Info (images, stack traces, etc)

Transpiling spread syntax, cannot find module

Operating System: Ubuntu 18.10
Cypress Version: 3.1.3
Browser Version: Electron 59 (headless)

Is this a Feature or Bug?

Bug

Current behavior:

It doesn't transpile at all.
Tried preset-es2015 and preset-env but none of them work.
Would appreciate an example.

Here is what I did
const options = webpack.defaultOptions options.webpackOptions.module.rules[0].use[0].options.presets.push( '@babel/preset-es2015' ) on('file:preprocessor', webpack(options))

Desired behavior:

It transpiles and runs in headless mode without crashing

How to reproduce:

Try out my config with simple object spread operators

Additional Info (images, stack traces, etc)

./tests/e2e/support/index.js
Module build failed (from ./node_modules/babel-loader/lib/index.js):
Error: Cannot find module '@babel/preset-es2015' from '/home/tjark/git/exomia-cloud/vue'

This occurred while Cypress was compiling and bundling your test code. This is usually caused by:

A missing file or dependency
A syntax error in the file or one of its dependencies

Fix the error in your code and re-run your tests.

reject is not defined

Operating System: macOS 10.12.6
Cypress Version: 1.1.0
Browser Version: n/a

Is this a Feature or Bug?

A bug.

Current behavior:

Opening Cypress results in:

ReferenceError: reject is not defined
    at EventEmitter.<anonymous> (/Users/hugo/Sites/goldfish/node_modules/cypress/dist/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/index.js:81:18)
    at emitTwo (events.js:106:13)
    at EventEmitter.emit (events.js:191:7)
    at ChildProcess.<anonymous> (/Users/hugo/Sites/goldfish/node_modules/cypress/dist/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/util.js:23:29)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at process.nextTick (internal/child_process.js:744:12)
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Desired behavior:

Not a crash. :)

How to reproduce:

Set up the following plugin file:

const webpack = require('@cypress/webpack-preprocessor')

module.exports = on => {
  on('file:preprocessor', webpack())
}

Additional Info (images, stack traces, etc)

Using import instead of require fails the same way.

Outdated Dependencies

Operating System: OSX 10.12
Cypress Version: 3.0.3
Browser Version: 68.0.3440.106

Is this a Feature or Bug?

Bug

Current behavior:

Using the newer babel, @babel/core: 7.0.0, cypress webpack-preprocessor doesn't work. It returns an error about dependencies needing to be updated.

./cypress/integration/notifications.js
Module build failed (from ./node_modules/@cypress/webpack-preprocessor/node_modules/babel-loader/lib/index.js):
Error: Requires Babel "^7.0.0-0", but was loaded with "6.26.0". If you are sure you have a compatible version of @babel/core, it is likely that something in your build process is loading the wrong version. Inspect the stack trace of this error to look for the first entry that doesn't mention "@babel/core" or "babel-core" to see what is calling Babel.

Looks like this is being fixed in #22

When your file has an error cypress closes the browser

Current behavior:

On a webpack error, cypress closes the browser with the error, you then have to manually reopen the browser after fixing the file.

Desired behavior:

Not close the browser. Don't run the test. Show me the error in the browser.

How to reproduce:

Get some working typescript tests. Enter some gibberish / breaking changes and boom. Cypress closes the browser with the error. You then have to fix it. Re-open browser.

e.g.

Additional Info (images, stack traces, etc)

Using the sample from https://github.com/cypress-io/cypress-webpack-preprocessor#usage

Operating System: MacOS Mojava
Cypress Version: 3.1.0
Browser Version: Chrome 69

Error: Cannot find module 'babel-preset-env'

Operating System:
macOS 10.15.2 (19C57)

$ npm --version
6.10.2
$ node --version
v12.8.1
$ nvm ls
->      v12.8.1
$ nvm --version
0.35.0

Cypress Version:

    "@babel/core": "^7.8.4",
    "@babel/preset-env": "^7.8.4",
    "@cypress/webpack-preprocessor": "^4.1.1",
    "babel-loader": "^8.0.6",
    "cypress": "^3.4.1",
    "webpack": "^4.41.5"

Browser Version:
Chrome
Version 79.0.3945.130 (Official Build) (64-bit)

Is this a Feature or Bug?

Bug

Current behavior:

Following readme on a brand new cypress install yields exception when looking for module 'babel-preset-env'

Desired behavior:

Get a basic webpack options file:preprocessor working.

How to reproduce:

[email protected]

git clone https://github.com/westhomas/cypress-playground -b webpack-preprocessor-3.4.1
cd cypress-playground && npm install && npm run test

[email protected]

git clone https://github.com/westhomas/cypress-playground -b webpack-preprocessor-4.0.0
cd cypress-playground && npm install && npm run test

Additional Info (images, stack traces, etc)

./cypress/integration/examples/actions.spec.js
Module build failed (from ./node_modules/babel-loader/lib/index.js):
Error: Cannot find module 'babel-preset-env' from '/Users/wes/Code/cypress-playground'
 @ multi ./cypress/integration/examples/actions.spec.js main[0]

My ultimate goal is to get support for the @babel/plugin-syntax-dynamic-import but I can't even get it to work in a basic way first.

Exception when doing a dynamic import: Uncaught SyntaxError: Unexpected token '<'

Operating System: macOS 10.15.2 (19C57)
Cypress Version: 3.4.1
Browser Version: Chrome Version 79.0.3945.130 (Official Build) (64-bit)

Is this a Feature or Bug?

Bug

Current behavior:

Exception when doing a dynamic import

Desired behavior:

No exception when using dynamic import feature.

How to reproduce:

git clone https://github.com/westhomas/cypress-playground -b webpack-preprocessor-3.4.1
cd cypress-playground && npm install && npm run test

This is the code generating the error:

// dynamic import test
async function load(){
    let {test_test_method} = await import("./testing.js")
}

load()

(https://github.com/westhomas/cypress-playground/blob/62c95a375a874d09fe72c44642cefc7501ea445d/cypress/integration/examples/actions.spec.js#L14-L19)

Additional Info (images, stack traces, etc)

Other babel features are working without error, so I know webpack is working. But this token issue is strange. I'm not sure what to make of it.

Console logs don't seem to have any relevant information:

$ npm run test

> [email protected] test /Users/wes/Code/cypress-playground
> DEBUG=cypress:webpack cypress open

  cypress:webpack user options: { webpackOptions: { mode: 'development', module: { rules: [Array] } },
  watchOptions: {} } +0ms
GET /__/ 200 17.154 ms - -
GET /__cypress/runner/cypress_runner.css 200 4.028 ms - -
GET /__cypress/runner/cypress_runner.js 200 3.399 ms - -
GET /__cypress/static/favicon.ico 200 0.858 ms - -
GET /__cypress/iframes/integration/examples/actions.spec.js 200 7.126 ms - 744
GET /__cypress/runner/fonts/fontawesome-webfont.woff2 200 0.587 ms - 77160
  cypress:webpack get /Users/wes/Code/cypress-playground/cypress/integration/examples/actions.spec.js +3s
  cypress:webpack webpackOptions: { mode: 'development', module: { rules: [ [Object] ] } } +0ms
  cypress:webpack watchOptions: {} +1ms
  cypress:webpack input: /Users/wes/Code/cypress-playground/cypress/integration/examples/actions.spec.js +0ms
  cypress:webpack output: /Users/wes/Library/Application Support/Cypress/cy/production/projects/cypress-playground-cb1b47fa0567de0b484d855198c71fe1/bundles/cypress/integration/examples/actions.spec.js +0ms
  cypress:webpack watching +110ms
  cypress:webpack compile /Users/wes/Code/cypress-playground/cypress/integration/examples/actions.spec.js +2ms
  cypress:webpack get /Users/wes/Code/cypress-playground/cypress/support/index.js +19ms
  cypress:webpack webpackOptions: { mode: 'development', module: { rules: [ [Object] ] }, entry: [ '/Users/wes/Code/cypress-playground/cypress/integration/examples/actions.spec.js' ], output: { path: '/Users/wes/Library/Application Support/Cypress/cy/production/projects/cypress-playground-cb1b47fa0567de0b484d855198c71fe1/bundles/cypress/integration/examples', filename: 'actions.spec.js' }, devtool: 'inline-source-map' } +0ms
  cypress:webpack watchOptions: {} +0ms
  cypress:webpack input: /Users/wes/Code/cypress-playground/cypress/support/index.js +0ms
  cypress:webpack output: /Users/wes/Library/Application Support/Cypress/cy/production/projects/cypress-playground-cb1b47fa0567de0b484d855198c71fe1/bundles/cypress/support/index.js +1ms
  cypress:webpack watching +4ms
  cypress:webpack compile /Users/wes/Code/cypress-playground/cypress/support/index.js +1ms
  cypress:webpack get /Users/wes/Code/cypress-playground/cypress/integration/examples/actions.spec.js +5ms
  cypress:webpack already have bundle for /Users/wes/Code/cypress-playground/cypress/integration/examples/actions.spec.js +0ms
  cypress:webpack finished bundling /Users/wes/Library/Application Support/Cypress/cy/production/projects/cypress-playground-cb1b47fa0567de0b484d855198c71fe1/bundles/cypress/support/index.js +694ms
  cypress:webpack - compile finished for /Users/wes/Code/cypress-playground/cypress/support/index.js +111ms
GET /__cypress/tests?p=cypress/support/index.js-477 - - ms - -
GET /__cypress/tests?p=cypress/integration/examples/actions.spec.js-883 - - ms - -
GET /__cypress/iframes/integration/examples/actions.spec.js 200 3.481 ms - 744
  cypress:webpack get /Users/wes/Code/cypress-playground/cypress/support/index.js +25ms
  cypress:webpack already have bundle for /Users/wes/Code/cypress-playground/cypress/support/index.js +0ms
  cypress:webpack get /Users/wes/Code/cypress-playground/cypress/integration/examples/actions.spec.js +1ms
  cypress:webpack already have bundle for /Users/wes/Code/cypress-playground/cypress/integration/examples/actions.spec.js +0ms
GET /__cypress/tests?p=cypress/support/index.js-309 200 3.336 ms - -
  cypress:webpack finished bundling /Users/wes/Library/Application Support/Cypress/cy/production/projects/cypress-playground-cb1b47fa0567de0b484d855198c71fe1/bundles/cypress/integration/examples/actions.spec.js +66ms
  cypress:webpack - compile finished for /Users/wes/Code/cypress-playground/cypress/integration/examples/actions.spec.js +0ms
GET /__cypress/tests?p=cypress/integration/examples/actions.spec.js-030 - - ms - -
GET /__cypress/iframes/integration/examples/actions.spec.js 200 3.148 ms - 744
  cypress:webpack get /Users/wes/Code/cypress-playground/cypress/support/index.js +21ms
  cypress:webpack already have bundle for /Users/wes/Code/cypress-playground/cypress/support/index.js +0ms
  cypress:webpack get /Users/wes/Code/cypress-playground/cypress/integration/examples/actions.spec.js +1ms
  cypress:webpack already have bundle for /Users/wes/Code/cypress-playground/cypress/integration/examples/actions.spec.js +0ms
GET /__cypress/tests?p=cypress/support/index.js-609 200 2.109 ms - -
GET /__cypress/tests?p=cypress/integration/examples/actions.spec.js-141 200 1.580 ms - -
GET /__cypress/iframes/integration/examples/0.actions.spec.js 200 2.947 ms - 748

Webpack is bundled

Why is webpack bundled within this plugin?

My app is using a different version of webpack, and the configs are incompatible. I've finally been able to move forward by rewriting my config and using a fragile combination of different loaders than I currently use to bundle my app, locked at specific versions that seem to work with this plugin (specifically, awesome-typescript-loader blows up, but [email protected] does not).

Having your app be compiled one way, and having your tests for that app (which imports your source files), be compiled another different way, seems pretty bad.

Why can't I bundle my tests with my own webpack and my own configuration, and simply supply the output to cypress?

Preprocessor doesn't transpile correctly, then fails to run afterwards

Operating System: Centos linux (inside docker though)
Cypress Version: 3.1.0
Browser Version: Electron 59

Is this a Feature or Bug?

Bug

Current behavior:

After 19 or 20 specs, the webpack preprocessor fails to transpile my typescript.
This is 100% reproducable on my system. Will look at getting a repo set up where I can share code later.

The cypress tests then thinks there are no tests in the spec and fails.

Desired behavior:

transpile my typescript

How to reproduce:

webpack.conf.js

const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');

module.exports = {
  resolve: {
    extensions: ['.ts', '.js'],
    plugins: [
      new TsconfigPathsPlugin({ configFile: "./tsconfig.json" })
    ]
  },
  devtool: 'source-map',
  module: {
    rules: [
      {
        test: /\.ts$/,
        exclude: [/node_modules/],
        use: [{
          loader: 'ts-loader',
        }],
      },
    ],
  },
}

make 21 specs, have it fail (not sure if it's spec number specific or not)

Additional Info (images, stack traces, etc)

Spec number 19 worked fine.

preprocessor invoked with {"domain":null,"_events":{},"_eventsCount":1,"filePath":"/usr/src/app/cypress/suites/cm/routes/operator.ts","outputPath":"/root/.config/Cypress/cy/production/projects/app-a14564dce24fc232216f1aef117728d1/bundles/cypress/suites/cm/routes/operator.ts","shouldWatch":false}
2018-10-18T12:34:37.285Z cypress:webpack user options: { webpackOptions:
   { resolve: { extensions: [Array], plugins: [Array] },
     devtool: 'source-map',
     module: { rules: [Array] } } }
2018-10-18T12:34:37.286Z cypress:webpack get /usr/src/app/cypress/suites/cm/routes/operator.ts
2018-10-18T12:34:37.286Z cypress:webpack input: /usr/src/app/cypress/suites/cm/routes/operator.ts
2018-10-18T12:34:37.286Z cypress:webpack output: /root/.config/Cypress/cy/production/projects/app-a14564dce24fc232216f1aef117728d1/bundles/cypress/suites/cm/routes/operator.ts
2018-10-18T12:34:37.296Z cypress:webpack compile /usr/src/app/cypress/suites/cm/routes/operator.ts
preprocessor returned "/root/.config/Cypress/cy/production/projects/app-a14564dce24fc232216f1aef117728d1/bundles/cypress/suites/cm/routes/operator.ts"
2018-10-18T12:34:50.121Z cypress:webpack warnings for /root/.config/Cypress/cy/production/projects/app-a14564dce24fc232216f1aef117728d1/bundles/cypress/suites/cm/routes/operator.ts
2018-10-18T12:34:50.121Z cypress:webpack [ 'configuration\nThe \'mode\' option has not been set, webpack will fallback to \'production\' for this value. Set \'mode\' option to \'development\' or \'production\' to enable defaults for each environment.\nYou can also set it to \'none\' to disable any default behavior. Learn more: https://webpack.js.org/concepts/mode/' ]
2018-10-18T12:34:50.121Z cypress:webpack finished bundling /root/.config/Cypress/cy/production/projects/app-a14564dce24fc232216f1aef117728d1/bundles/cypress/suites/cm/routes/operator.ts
2018-10-18T12:34:50.121Z cypress:webpack - compile finished for /usr/src/app/cypress/suites/cm/routes/operator.ts

spec 20 seems to hang

  Running: cm/routes/user.ts...                                      (20 of 43)
  Estimated: 2 minutes, 32 seconds
preprocessor invoked with {"domain":null,"_events":{},"_eventsCount":1,"filePath":"/usr/src/app/cypress/suites/cm/routes/user.ts","outputPath":"/root/.config/Cypress/cy/production/projects/app-a14564dce24fc232216f1aef117728d1/bundles/cypress/suites/cm/routes/user.ts","shouldWatch":false}
2018-10-18T12:36:18.755Z cypress:webpack user options: { webpackOptions:
   { resolve: { extensions: [Array], plugins: [Array] },
     devtool: 'source-map',
     module: { rules: [Array] } } }
2018-10-18T12:36:18.755Z cypress:webpack get /usr/src/app/cypress/suites/cm/routes/user.ts
2018-10-18T12:36:18.755Z cypress:webpack input: /usr/src/app/cypress/suites/cm/routes/user.ts
2018-10-18T12:36:18.755Z cypress:webpack output: /root/.config/Cypress/cy/production/projects/app-a14564dce24fc232216f1aef117728d1/bundles/cypress/suites/cm/routes/user.ts
2018-10-18T12:36:18.767Z cypress:webpack compile /usr/src/app/cypress/suites/cm/routes/user.ts

Spec 21 doesn't seem to fire the preprocessor event

────────────────────────────────────────────────────────────────────────────────

  Running: cm/schedule/participants.ts...                            (21 of 43)
  Estimated: 2 minutes, 29 seconds


  0 passing (39ms)

My plugin usage: (trying to be as verbose as possible).

const webpack = require('@cypress/webpack-preprocessor');
const fs = require('fs');

module.exports = (on) => {
  const options = {
    webpackOptions: require('../../webpack.config'),
  };

  console.log(`Webpack options set as ${JSON.stringify(options)}`)

  on('file:preprocessor', (file) => {
    console.log(`preprocessor invoked with ${JSON.stringify(file)}`);
    return webpack(options)(file).then((results) => {
      console.log(`preprocessor returned ${JSON.stringify(results)}`);

      if (!fs.existsSync(file.outputPath)) {
        console.error(`Output file does not exist on the filesystem: ${JSON.stringify(file)}`);
        throw new Error(`Output file does not exist on the filesystem: ${JSON.stringify(file)}`);
      }
      return results;
    }).catch((err) => {
      console.error(`Error occurred running preprocessor`, err);
      throw err;
    });
  })
};

Breaks Eslint in Project

Operating System: MacOS
Cypress Version: 2.1.0
Browser Version: N/A

Is this a Feature or Bug?

Bug

Current behavior:

Installing this as a dependency breaks ESLinter - Eslinter fails to recognize experimental values

Eslint deps:
babel-eslint: ^7.2.3
eslint: ^3.19.9
eslint-plugin-cypress: ^2.0.1

My eslint config:

module.exports = {
  plugins: ['cypress'],
  env: {
    browser: true,
    es6: true,
    node: true,

    'cypress/globals': true,
  },
  extends: 'eslint:recommended',
  parser: 'babel-eslint',
  parserOptions: {
    sourceType: 'module',
  },
  rules: {
    indent: ['error', 2, { SwitchCase: 1 }],
    'linebreak-style': ['error', 'unix'],
    quotes: [
      'error',
      'single',
      { allowTemplateLiterals: true, avoidEscape: true },
    ],
    semi: ['error', 'always'],
    'one-var': [2, 'never'],
    'no-unused-vars': [2, { args: 'none' }],
  },
};

Desired behavior:

I should be able to use the preprocessor without it interfering with my Eslint options.

How to reproduce:

It should theoretically be reproducable with my eslint options and using experimental class features

babel/babel-eslint#487

Note the static and stuff. This results in false negatives when i have this preprocessor installed, but not when i do not. Very frustrating!

Incorrectly listening to 'compile' event and emitting 'rerun' when 'shouldWatch' is false

In Cypress run mode, when shouldWatch is false, we still listen to the 'compile' event and emit 'rerun', causing indefinite hanging or really-long compile times. We should only listen to 'compile' if shouldWatch is true.

Enable source maps by default

Unless explicitly disabled by the user.

Figure out why .babelrc is not loaded automatically

In https://github.com/bahmutov/react-loading-skeleton/blob/master/cypress/plugins/use-babelrc.js

we have to load same presets and plugins as the project's .babelrc already loads in https://github.com/bahmutov/react-loading-skeleton/blob/master/.babelrc

We need to figure out how to simply say "use .babelrc with babel-loader"

Silent / wrong error message if the user forgets to install `ts-loader`

I think this is a bug

Cypress 1.1.2
@cypress/[email protected]

start new project
install Cypress
install @cypress/webpack-preprocessor
create webpack.config.js file, for example in the root with recommended example options in the typescript webpack example

https://github.com/cypress-io/cypress-example-recipes/blob/master/examples/preprocessors__typescript-webpack/cypress/plugins/index.js

https://github.com/cypress-io/cypress-example-recipes/blob/master/examples/preprocessors__typescript-webpack/webpack.config.js

I like putting webpack.config.js right next to the plugins/index.js file

// plugins/index.js
const wp = require('@cypress/webpack-preprocessor')

module.exports = (on) => {
  const options = {
    webpackOptions: require('./webpack.config'),
  }
  on('file:preprocessor', wp(options))
}

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

note I forgot to install ts-loader as dev dependency.

start Cypress with debug output DEBUG=cypress:* $(npm bin)/cypress open
click on the spec.ts file

But the actual problem in the debug log

  cypress:server:controllers:spec send /Users/irinakous/Library/Application Support/Cypress/cy/production/projects/test-ts-a2194cba4a58c59bbe6f6fefa72b735c/bundles/cypress/integration/spec.ts +1ms
Error: ENOENT: no such file or directory, stat '/Users/irinakous/Library/Application Support/Cypress/cy/production/projects/test-ts-a2194cba4a58c59bbe6f6fefa72b735c/bundles/cypress/integration/spec.ts'
    at Error (native)

Error: ENOENT: no such file or directory, stat '/Users/irinakous/Library/Application Support/Cypress/cy/production/projects/test-ts-a2194cba4a58c59bbe6f6fefa72b735c/bundles/cypress/integration/spec.ts'
    at Error (native)

GET /__cypress/tests?p=cypress/integration/spec.ts-134 500 63.710 ms - 21

We get 500 error trying to bundle spec file using non-installed ts-loader module, but we do not communicate this error to the user.

Set mode: development

When using Webpack it is recommended to set mode which allows plugins and presets to be set correctly.

https://webpack.js.org/configuration/mode/

We should set mode: development by default if not specified

What depencies is required?

Operating System: Windows
Cypress Version: 3.1.4
Browser Version: Chrome: 71.0.3578.98

Is this a Feature or Bug?

Feature

Current behavior:

Currently in the package.json there is a list of dependencies and devDependencies but the are needed if you want to run all of the Examples-Recipes.

Desired behavior:

On the specific examples like "cypress-webpack-preprocessor" place the needed package.json or mention the needed packages.

How to reproduce:

Go to https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/preprocessors__typescript-webpack
You now do not see the packages needed to make it work.

Add types

Hey! Could we add these types to the repository so TS users don't have to define them manually? 😄

declare module '@cypress/webpack-preprocessor' {
  import * as webpack from 'webpack';

  type FilePreprocessor = (file: Cypress.FileObject) => string | Promise<string>;

  namespace _default {
    export type Options = { webpackOptions: webpack.Configuration };
  }

  const _default: (options: _default.Options) => FilePreprocessor;

  export = _default;
}

cypress-io / cypress-webpack-preprocessor Goto Github PK

cypress-webpack-preprocessor's Introduction

Cypress Webpack Preprocessor

🚚 This repo has been moved

@cypress/webpack-preprocessor now lives in the main Cypress monorepo

cypress-webpack-preprocessor's People

Contributors

Stargazers

Watchers

Forkers

cypress-webpack-preprocessor's Issues

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Additional Info (images, stack traces, etc)

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Current behavior:

Desired behavior:

How to reproduce:

Additional Info (images, stack traces, etc)

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Additional Info (images, stack traces, etc)

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Additional Info (images, stack traces, etc)

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Additional Info (images, stack traces, etc)

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Additional Info (images, stack traces, etc)

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Additional Info (images, stack traces, etc)

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Additional Info (images, stack traces, etc)

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Additional Info (images, stack traces, etc)

Is this a Feature or Bug?

Current behavior:

Desired behavior:

How to reproduce:

Additional Info (images, stack traces, etc)

before

after

Other possible solutions

Is this a Feature or Bug?

`@cypress/webpack-preprocessor` now lives in the main Cypress monorepo