* chore: [run ci] does further prerequisites for webpack 5: https://webpack.js.org/migrate/5/#make-sure-your-build-has-no-errors-or-warnings https://webpack.js.org/migrate/5/#make-sure-to-use-mode https://webpack.js.org/migrate/5/#update-outdated-options https://webpack.js.org/migrate/5/#test-webpack-5-compatibility app builds and runs locally. Time to test out in CI and see if buffer or process need to be polyfilled by the build * chore: upgrade to webpack 5 and do the bare minimum to get it working * chore: get @packages/extension working * chore: add TODOs to finish after webpack 5 update * chore: update the webpack config for npm/webpack-batteries-included-preprocessor to be webpack 5 compliant * chore: patch whatwg-url 7.1.0. package 'source-map' uses whatwg-url@7.1.0 which has a dependency on punycode node expected API. since punycode is now polyfilled for us implicitly via the punycode npm package, the API signatures are a bit different https://github.com/mathiasbynens/punycode.js/blob/main/punycode.js#L101 vs https://nodejs.org/api/punycode.html#punycodeucs2. The patch uses the punycode npm package expected API and is needed for source maps to work for cy.origin() dependencies for Cypress.require() * chore: convert whatwg patch into dev patch as source-map is not installed when building the binary / installing prod dependencies * chore: only move production level patches into the binary dist directory for yarn install --production * chore: remove --openssl-legacy-provider code for node versions 17 and over as webpack has been updated to v5 * chore: fix the webpack-batteries-included-preprocessor tests by shimming the correct node globals and built ins * chore: provide the define plugin and evalDevtoolPlugin again as we need define in order to build the react-dom library correctly in the bundle to not include the development version * chore: updating v8 snapshot cache * chore: updating v8 snapshot cache * chore: updating v8 snapshot cache * chore: fix the webpack preprocessor not to change promise references under the hood when compiling the first bundle, as it was causing the webpack preprocessor to hang as the reference itself was different * chore: fix issues from readFile that were caused by Webpack 5 using 'path-browserify' * chore: update chrome component testing snapshots to match Webpack 5 changes * chore: fix mismatched snapshots from webpack 5 update * chore: use Cypress.Buffer instead of Buffer for selectFile system test to avoid having to polyfill Buffer from webpack * chore: fix system test webpack path that now includes e2e workspace * chore: patch enhanced-resolve to properly discover the pnp api for the yarn_v3.1.1_pnp_spec.ts system test. see https://github.com/webpack/enhanced-resolve/issues/263 for more details * chore: set stats to 'none' for experimentalSingleTabMode to prevent different webpack compiled terminal formatting in the snapshot between local and CI. * chore: fix node built in tests and configure webpack-batteries-included-preprocessor correctly * chore: fallback to buffer correctly in config, even though there is no impact due to the provide plugin * Update binary-cleanup.js to exclude added build dependencies for webpack 5 added by webpack-terser-plugin under the hood * chore: add stream-browserify to webpack preprocessor batteries included as a dep as its used in the config [run ci] * chore: make sure process and buffer are installed in the CLI for webpack provide * chore: build cross platform binaries [run ci] * chore: fix webpack evalDevToolPlugin instantiation [run ci] * run all binary jobs [run ci] * chore: updating v8 snapshot cache * add find-up to the entry points that need to be kept * chore: updating v8 snapshot cache * chore: updating v8 snapshot cache * chore: fix mocha build warnings * chore: fix STRIPPED_INTEGRITY_TAG import warnings * chore: add changelog event --------- Co-authored-by: cypress-bot[bot] <+cypress-bot[bot]@users.noreply.github.com> Co-authored-by: Ryan Manuel <ryanm@cypress.io>
CLI
The CLI is used to build the cypress npm module to be run within a terminal.
The CLI has the following responsibilities:
- Allow users to print CLI commands
- Allow users to install the Cypress executable
- Allow users to print their current Cypress version
- Allow users to run Cypress tests from the terminal
- Allow users to open Cypress in the interactive Test Runner.
- Allow users to verify that Cypress is installed correctly and executable
- Allow users to manages the Cypress binary cache
- Allow users to pass in options that change way tests are ran or recorded (browsers used, specfiles ran, grouping, parallelization)
Building
See scripts/build.js. Note that the built npm package will include NPM_README.md as its public README file.
Testing
Automated
From the repo's root, you can run unit tests with:
yarn test-unit --scope cypress
yarn test-watch --scope cypress
yarn test-debug --scope cypress
Updating snapshots
Prepend SNAPSHOT_UPDATE=1 to any test command. See snap-shot-it instructions for more info.
SNAPSHOT_UPDATE=1 yarn test-unit --scope cypress
Type Linting
When testing with dtslint, you may need to remove existing typescript installations before running the type linter (for instance, on OS X, you might rm -rf ~/.dts/typescript-installs) in order to reproduce issues with new versions of typescript (i.e., @next).
Manual
To build and test an NPM package:
yarnyarn build
This creates build folder.
cd build; yarn pack
This creates an archive, usually named cypress-v<version>.tgz. You can install this archive from other projects, but because there is no corresponding binary yet (probably), skip binary download. For example from inside cypress-example-kitchensink folder
yarn add ~/{your-dirs}/cypress/cli/build/cypress-3.3.1.tgz --ignore-scripts
Which installs the tgz file we have just built from folder Users/jane-lane/{your-dirs}/cypress/cli/build.
Sub-package API
How do deep imports from cypress/* get resolved?
The cypress npm package comes pre-assembled with mounting libraries for major front-end frameworks. These mounting libraries are the first examples of Cypress providing re-exported sub-packages. These sub-packages follow the same naming convention they do when they're published on npm, but without a leading @ sign. For example:
An example of a sub-package: @cypress/vue, @cypress/react, @cypress/mount-utils
Let's discuss the Vue mounting library that Cypress ships.
If you'd installed the @cypress/vue package from NPM, you could write the following code.
This would be necessary when trying to use a version of Vue, React, or other library that may be newer or older than the current version of cypress itself.
import { mount } from '@cypress/vue'
Now, with the sub-package API, you're able to import the latest APIs directly from Cypress without needing to install a separate dependency.
import { mount } from 'cypress/vue'
The only difference is the import name, and if you still need to use a specific version of one of our external sub-packages, you may install it and import it directly.
Adding a new sub-package
There are a few steps when adding a new sub-package.
- Make sure the sub-package's rollup build is self-contained or that any dependencies are also declared in the CLI's
package.json. - Now, in the
postbuildscript for the sub-package you'd like to embed, invokenode ./scripts/sync-exported-npm-with-cli.js(relative to the sub-package, seenpm/vuefor an example). - Add the sub-package's name to the following locations:
cli/.gitignorecli/scripts/post-build.js.eslintignore(under cli/sub-package)
- DO NOT manually update the package.json file. Running
yarn buildwill automate this process. - Commit the changed files.
Here is an example Pull Request
Module API
The module API can be tested locally using something like:
/* @ts-ignore */
import cypress from '../../cli/lib/cypress'
const run = cypress.run as (options?: Partial<CypressCommandLine.CypressRunOptions>) => Promise<CypressCommandLine.CypressRunResult | CypressCommandLine.CypressFailedRunResult>
run({
spec: './cypress/component/advanced/framer-motion/Motion.spec.tsx',
testingType: 'component',
/* @ts-ignore */
dev: true,
}).then(results => {
console.log(results)
})
Note that the dev flag is required for local testing, as otherwise the command will fail with a binary error.