Skip to content
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: Defaulting nodeVersion to system #18732

Merged
merged 11 commits into from
Nov 4, 2021
Merged

feat: Defaulting nodeVersion to system #18732

merged 11 commits into from
Nov 4, 2021

Conversation

mjhenkes
Copy link
Member

@mjhenkes mjhenkes commented Nov 1, 2021

User facing changelog

Breaking:
The nodeVersion configuration option now defaults to system. The behavior of the system option has changed to always use the node binary/version of the cli that launched the cypress app. If the cli was not used to launch the app, cypress will use the node version bundled with electron.

Suggestion:
Breaking:

  • The nodeVersion configuration option now defaults to system, which uses your node version instead of the built in one in Cypress. We don't anticipate this causing any issues, but if you'd like to revert to the old behavior, set nodeVersion back to 'bundled'.
  • Additionally, the meaning of system has changed - previous Cypress would search for the node version that was default to your system, and now it uses whatever node version was used to launch cypress from the CLI.

Additional details

How has the user experience changed?

There are now two deprecation messages.

When "nodeVersion": "bundled" is set:

Screen Shot 2021-11-03 at 2 52 44 PM

When "nodeVersion": "system" is set:

Screen Shot 2021-11-03 at 2 41 51 PM

There is no deprecation notice when nodeVersion is unset.

We also now display the node version by default when running tests run mode.

Before:

Screen Shot 2021-11-03 at 4 22 21 PM

After:

Screen Shot 2021-11-03 at 4 21 01 PM

PR Tasks

@mjhenkes mjhenkes requested a review from a team as a code owner November 1, 2021 18:17
@mjhenkes mjhenkes requested review from jennifer-shehane and removed request for a team November 1, 2021 18:17
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Nov 1, 2021

Thanks for taking the time to open a PR!

@mjhenkes mjhenkes changed the title Defaulting nodeVersion to system feat: Defaulting nodeVersion to system Nov 1, 2021
@jennifer-shehane jennifer-shehane removed their request for review November 1, 2021 18:28
@cypress
Copy link

cypress bot commented Nov 1, 2021



Test summary

4214 0 50 2Flakiness 0


Run details

Project cypress
Status Passed
Commit f8fd333
Started Nov 4, 2021 4:57 PM
Ended Nov 4, 2021 5:07 PM
Duration 09:52 💡
OS Linux Debian - 10.9
Browser Chrome beta 96

View run in Cypress Dashboard ➡️


This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

@@ -81,7 +81,7 @@ module.exports = {
args = [args]
}

args = [...args, '--cwd', process.cwd()]
args = [...args, '--cwd', process.cwd(), '--cliNodePath', process.execPath, '--cliNodeVersion', process.versions.node]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would call these args --userNodePath and --userNodeVersion instead of CLI, since CLI is an implementation detail, but user is the actual descriptor.

@@ -5,11 +5,10 @@ exports['e2e system node uses system node when launching plugins file 1'] = `
(Run Starting)

┌────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Cypress: 1.2.3 │
│ Browser: FooBrowser 88 │
│ Node Version: vX (/foo/bar/node) │
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It still might be useful to log this message for anyone that might spawn this programmatically or provide an override version via the CLI.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The presence of the node version message is based on whether resolvedNodePath is undefined or not. In this case since the test is not initiated via the cypress cli, there isn't a userNodePath or version defined so the test falls back to the bundled node version. So this feature isn't removed it's just not being triggered in this test.

https://github.com/cypress-io/cypress/blob/develop/packages/server/lib/modes/run.js#L151

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figured out a better way to fix this test so the snapshot should be the same now.

Copy link
Member

@emilyrohrbough emilyrohrbough left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the cli was not used to launch the app, cypress will use the node version bundled with electron.

Any way for user to set the version from the config.json if they launch programmatically?

@brian-mann
Copy link
Member

We may want to consider removing nodeVersion from cypress.json entirely.

The GUI will already tell you which node version you're using, and I don't really see a use case anymore for forcing it to be bundled.

@mjhenkes
Copy link
Member Author

mjhenkes commented Nov 2, 2021

@brian-mann it makes sense to remove nodeVersion. I wasn't sure if there was a case where using the user node version may be a problem and we should give the user a way to fall back to the bundled version.

@mjhenkes
Copy link
Member Author

mjhenkes commented Nov 2, 2021

@emilyrohrbough

Any way for user to set the version from the config.json if they launch programmatically?

no, there is not a way to set an exact node version in the config. I think we're trying to avoid that?

Copy link
Member

@emilyrohrbough emilyrohrbough left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Just need the docs PR.

@jennifer-shehane
Copy link
Member

@brian-mann I agree that I don't see much value in offering the nodeVersion config value in the future. I would like to deprecate the nodeVersion config through the next major version and remove it after that.

I think that deprecating will help de-risk the initial change to system node. People will have a fallback in case there is some edge case we may have missed (with windows file system or something for example). They can quickly switch to bundle instead of us having to rush out a patch release.

@mjhenkes mjhenkes self-assigned this Nov 2, 2021
@@ -306,7 +307,6 @@ export function mergeDefaults (config: Record<string, any> = {}, options: Record
return setSupportFileAndFolder(config)
.then(setPluginsFile)
.then(setScaffoldPaths)
.then(_.partialRight(setNodeBinary, options.onWarning))
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no more promises here so we can just call the function

@@ -151,8 +151,7 @@ export const options = [
isInternal: true,
}, {
name: 'nodeVersion',
defaultValue: 'default',
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default value is removed so that the depreciation warning will only fire when the 'nodeVersion' config is present.

@@ -65,8 +64,13 @@ const convertRelativeToAbsolutePaths = (projectRoot, obj, defaults = {}) => {
}

const validateNoBreakingConfig = (cfg) => {
return _.each(breakingOptions, ({ name, errorKey, newName, isWarning }) => {
if (_.has(cfg, name)) {
breakingOptions.forEach(({ name, errorKey, newName, isWarning, value }) => {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated this to allow me to flex the warning message on the value of the config option

@@ -1010,6 +1010,16 @@ const getMsgByType = function (type, arg1 = {}, arg2, arg3) {
${arg1 ? 'Try installing Node.js 64-bit and reinstalling Cypress to use the 64-bit build.'
: 'Consider upgrading to a 64-bit OS to continue using Cypress.'}
`
case 'NODE_VERSION_DEPRECATION_SYSTEM':
return stripIndent`\
Deprecation Warning: ${chalk.yellow(`\`nodeVersion\``)} is currently set to ${chalk.yellow(`\`system\``)} in the ${chalk.yellow(`\`cypress.json\``)} configuration file. As of Cypress v9 the default behavior of ${chalk.yellow(`\`nodeVersion\``)} has changed to always use the version of Node used to start cypress via the cli.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, but i would recommend using v9.0.0 or 9.0.0 instead of v9 for consistency. I believe other errors/warnings use the full version segments. Check around for how other errors/warn use the pattern.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the point the breaking options are validated for the configuration, this value technically could have come from multiple places, config.json, config.ts, or cypress.config.js.

The file correct configFile is set here, which will use the project_utils's getDefaultConfigFilePath func to determine which cypress configuration file is found or it falls back to cypress.json.

Can we pass the configFie used into the error message as an additional argument?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@emilyrohrbough, good idea. I can make that flex.

@flotwig flotwig self-requested a review November 4, 2021 15:37
const validateNoBreakingConfig = (cfg) => {
return _.each(breakingOptions, ({ name, errorKey, newName, isWarning }) => {
if (_.has(cfg, name)) {
const validateNoBreakingConfig = ({ config, configFile }) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The resolved configFile from option should be available on config. Should be able to pull like:

(cfg) = > {
const { configFile } = cfg

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed you are correct!

})
})
}

module.exports = {
findNodeInFullPath,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh crap. Was gonna ask why this is here, but I forgot that findNodeInFullPath is used in the darwin child_process spawn workaround. We only use it in one place:

export async function darwinDetectionWorkaround (): Promise<FoundBrowser[]> {
const nodePath = await findSystemNode.findNodeInFullPath()
let args = ['./detection-workaround.js']
if (process.env.CYPRESS_INTERNAL_ENV === 'development') {
args = ['-r', '@packages/ts/register.js'].concat(args)
}
const { stdout } = await utils.execa(nodePath, args, { cwd: __dirname })
return JSON.parse(stdout)
}

The reason we need to use the system node here is a bug in Electron that causes cp.spawn to be very slow on darwin, which causes our browser detection to be very slow. I guess it's not an option to remove node-which entirely yet then since we'd have to make performance bad for global-mode users on darwin during browser detection.

Comment on lines +63 to +64
userNodePath: expectedNodePath,
userNodeVersion: expectedNodeVersion,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't be too big of a change to system-tests.ts to add a useCli option, so that it spawns the cli instead of server. Would be useful for really fully system testing stuff like this. This is fine too for now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a good idea but I don't want to tack it onto this PR. I created this issue: #18795 to track this request.

@mjhenkes mjhenkes merged commit 82429c0 into 9.0-release Nov 4, 2021
@mjhenkes mjhenkes deleted the issue-18684 branch November 4, 2021 18:45
@mjhenkes mjhenkes mentioned this pull request Nov 4, 2021
1 task
flotwig pushed a commit that referenced this pull request Nov 8, 2021
* Defaulting nodeVersion to system

* try to fix system test

* Rename arg parameters, fix system test in a much better way.

* remove invalid comment

* Add deprecation warning for the nodeVersion config.

* Remove default value to avoid warning regardless of the presence of `nodeVersion`

* More tests fixes 😅

* Updates to deprecation message

* update node version in deprecation notice.

* flex config file name that we tell consumers to update

* simplify validateNoBreakingConfig options
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants