-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: embedding mount into the cypress binary (real dependency) #20930
Changes from all commits
a521e23
cbbfeb0
82d0612
0ed39a2
d2ad51e
93a6ad1
4cb6e86
a27b22f
d78b326
5ef22fa
4d49004
69325f4
30e2a8d
c036fca
0dfe5ae
ca18b0a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
const shell = require('shelljs') | ||
const { resolve } = require('path') | ||
|
||
shell.set('-v') // verbose | ||
shell.set('-e') // any error is fatal | ||
|
||
// For each npm package that is re-published via cypress/* | ||
// make sure that it is also copied into the build directory | ||
const npmModulesToCopy = [ | ||
'mount-utils', | ||
'react', | ||
'vue', | ||
] | ||
|
||
npmModulesToCopy.forEach((folder) => { | ||
// cli/mount-utils => cli/build/mount-utils | ||
const from = resolve(`${__dirname}/../${folder}`) | ||
const to = resolve(`${__dirname}/../build/${folder}`) | ||
|
||
shell.cp('-R', from, to) | ||
}) |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -22,6 +22,10 @@ includeTypes.forEach((folder) => { | |
shell.cp('-R', source, 'build/types') | ||
}) | ||
|
||
// TODO: Add a typescript or rollup build step | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a github issue for this we can link? Have been trying to do There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There isn't right now. |
||
// The only reason start-build.js exists | ||
// is because the cli package does not have an actual | ||
// build process to compile index.js and lib | ||
shell.exec('babel lib -d build/lib') | ||
shell.exec('babel index.js -o build/index.js') | ||
shell.cp('index.mjs', 'build/index.mjs') |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,78 @@ | ||
/** | ||
* This script is used to re-export packages that Cypress publishes on its own. | ||
* It is executed individually in a postbuild step by individual npm/* packages. | ||
* For example, usually, Cypress will publish the `npm/react` directory as a `@cypress/react` package. | ||
* However, the Cypress binary will also ship an export for `cypress/react` that's guaranteed to work | ||
* with this version of the binary | ||
*/ | ||
const shell = require('shelljs') | ||
const path = require('path') | ||
const packlist = require('npm-packlist') | ||
const fs = require('fs') | ||
|
||
shell.set('-v') // verbose | ||
shell.set('-e') // any error is fatal | ||
|
||
// This script will be run in a postbuild task for each npm package | ||
// that will be re-exported by Cypress | ||
const currentPackageDir = process.cwd() | ||
|
||
// 1. We'll run npm's own "packlist" against the npm package to be published (@cypress/react, etc) | ||
// to make sure we don't miss any files when we copy them over to the CLI package | ||
// The files that will be returned here are the ones from @cypress/react's package.json['files'] key. | ||
packlist({ path: currentPackageDir }) | ||
.then((files) => { | ||
// 2. Move all of the files that would be published under @cypress/react | ||
// to be copied under cli/react (drop the @cypress namespace) | ||
const cliPath = path.join(__dirname, '..', 'cli') | ||
|
||
// Typically, these packages are independently published as @cypress/package-name | ||
// e.g. @cypress/vue => import whatever from 'cypress/vue' | ||
// The files will wind up at cypress/cli/vue/* | ||
const currentPackageConfig = require(path.join(process.cwd(), 'package.json')) | ||
const exportName = currentPackageConfig.name.replace('@cypress/', '') | ||
const outDir = path.join(cliPath, exportName) | ||
|
||
// 3. For each file, mkdir if not exists, and then copy the dist'd assets over | ||
// Shell is synchronous by default, but we don't actually need to await for the results | ||
// to write to the `cliPackageConfig` at the end | ||
files.forEach((f) => { | ||
// mkdir if not exists | ||
const { dir } = path.parse(f) | ||
|
||
if (dir) { | ||
shell.mkdir('-p', path.join(outDir, dir)) | ||
} | ||
|
||
shell.cp(path.join(currentPackageDir, f), path.join(outDir, f)) | ||
}) | ||
|
||
// After everything is copied, let's update the Cypress cli package.json['exports'] map. | ||
const isModule = currentPackageConfig.type === 'module' | ||
|
||
const cliPackageConfig = require(path.join(cliPath, 'package.json')) | ||
|
||
const subPackageExports = cliPackageConfig.exports[`./${exportName}`] = {} | ||
const esmEntry = isModule ? currentPackageConfig.main : currentPackageConfig.module | ||
|
||
if (esmEntry) { | ||
// ./react/dist/cypress-react-esm.js, etc | ||
subPackageExports.import = `./${exportName}/${esmEntry}` | ||
} | ||
|
||
if (!isModule) { | ||
// ./react/dist/cypress-react-cjs.js, etc | ||
subPackageExports.require = `./${exportName}/${currentPackageConfig.main}` | ||
} | ||
|
||
if (!cliPackageConfig.files.includes(exportName)) { | ||
cliPackageConfig.files.push(exportName) | ||
} | ||
|
||
const output = `${JSON.stringify(cliPackageConfig, null, 2) }\n` | ||
|
||
// eslint-disable-next-line no-console | ||
console.log('Writing to CLI package.json for', exportName) | ||
|
||
fs.writeFileSync(path.join(cliPath, 'package.json'), output, 'utf-8') | ||
}) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The tiniest thing but this seems like pretty important logic to test - do we need some kind of basic test to ensure that the I wonder if we can update all internal code to use the deep import syntax in the future. Is this something we plan to do? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can test it by adding code here cypress-io/cypress-example-kitchensink#528 I'll do that. It'll break all other pipelines until this is merged, maybe I'll create a new branch for it (in kitchensink). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was also wondering if we can convert a couple of the existing system tests to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That probably only works in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah in general I feel uncomfortable that we don't have a lot of post-build infrastructure for testing the output of Circle CI's build scripts. The kitchen sink is the right place. I put a PR up above that will at least fail if those packages aren't declared in the exports map. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No import entry for mount-utils?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No it wasn't built for ESM.
Because only cypress-react and cypress-vue consume it and they have an esm export it's not (currently) a problem.
We have tech debt to convert all of our npm/* packages to be esm-first and share the same rollup + typescript compilation settings.