feat: make cypress.config.js available #17000

elevatebart · 2021-06-17T22:41:38Z

closes #5218

Summary

In preparation for the unified runner project, we need to be able to detect which testing types have been setup.
For this detection, we plan on using e2e and component function. So we need those functions to be there before unification.

cypress.json cypress.config.ts

To configure cypress, we can now use cypress.config.ts or cypress.config.js instead of cypress.json.
Using a ts or js file to store config needs cypress to execute/evaluate the file in a node context.
Since this is user code, this could throw a parsing/runtime error and crash the electron runner.
To avoid crashing, we spawn another process to parse the file. It allows cypress to elegantly handle each error.

One downside of using a separate process is this:
Functions in this config file cannot be transmitted to the main process.
We don't get the new e2e and component functions in the config object passed around everywhere.
It matters very little since they are supposed to be run in another child process anyway (see run_plugin.js) but it is worth noting.

Default config file

Three default config files are now possible: cypress.json, cypress.config.js and cypress.config.ts. If more than one of those files is present at the root of the project, the system errors because of abiguity.

Creating missing file

Before, when the targeted config file did not exist cypress would create it and populate it with the arguments passed to the CLI.
It still does that if a json config file is specified in the CLI. It creates a config file by default if a js or ts file is specified and not found. By default, it's going to create a cypress.config.js file.

Plugins definition functions

Before, all the servers and preprocessors had to be defined in the pluginsFile. This js/ts file whose path was configured in cypress.json was executed when loading a project on the cypress server. It allowed users to modify the cypress config depending on execution context and setup preprocessors, tasks and event handlers. It exported a function like below.

const { startDevServer } = require('@cypress/webpack-dev-server')

module.exports = (on, config) => {
  on('dev-server:start', (options) => {
    return startDevServer({ options, webpackConfig })
  })

  require('@cypress/code-coverage/task')(on, config)
  return config
}

Though we can still do that, now we can set this up directly in the cypress.config.ts.
Note how we setup the dev-server for component testing as a separate function setupDevServer.

export default {
    // ...
    component: {
        setupDevServer (options) {
            return startDevServer({ options, webpackConfig })
        },
        setupNodeEvents (on, config) {
             require('@cypress/code-coverage/task')(on, config)
             return config
        }
    }
}

If a plugins function and a pluginsFile are implemented, the system will throw an error. We want to avoid halfway migration.

Technical implementation

When it gets time to execute the pluginsFile, if config.component is a function,
we replace the configured pluginsFile with configFilePath and tell the plugins resolver what function it is supposed to execute.
Else, I let the pluginsFile run as before.

For now, if neither the pluginsFile nor the functions in cypress.config.ts exist, cypress creates sample plugins file. This avoids breaking tests but encourages the creation of a deprecated configuration.

This should be avoided.

defineConfig()

Vite, Vue CLI 4, windicss and a few other libraries have implemented a pattern for configuring their APIs that is very practical: a defineConfig() function.
This enables autocompletion and inline documentation in the config file while minimizing boilerplate.
Here is how to use it.

import { defineConfig } from "cypress"

export default defineConfig({
    baseUrl: "./substack/"
})

desktop-gui

As a consequence of these changes, the desktop-gui was displaying some wrong info in the settings tab.

Here are my fixes:

Deprecation warnings

To give a heads up about this necessary change. We add a warning both in the component testing runner and in the desktop GUI.

To see the desktop warning:

yarn start
open "packages/example" project
see the screenshot below

To see the warning in the component testing runner

cd npm/react/examples/react-scripts
yarn cy:open
see this screnshot

Technical detail

We had to wire up the component testing runner to receive warnings in the first place.

Look in server-ct/src/index.ts to see how it was done.

Remaining work before merge

These tasks remain once this change is approved.
They have to be accomplished before we deliver this to users to give them a solution when they see the deprecation.

Review text of errors and warnings
Create and merge codemods in this branch
Have a clear documentation ready to publish

cypress-bot · 2021-06-17T22:41:41Z

Thanks for taking the time to open a PR!

Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

cypress · 2021-06-22T15:30:47Z

Test summary

18540 • 0 • 214 • 7 • 2

Run details


Project	cypress
Status	Passed
Commit	`a120c2c`
Started	Oct 2, 2021 9:42 PM
Ended	Oct 2, 2021 9:54 PM
Duration	11:39 💡
OS	Linux Debian - 10.9
Browser	Multiple

View run in Cypress Dashboard ➡️

Flakiness

	commands/net_stubbing_spec.ts	1
1	network stubbing > waiting and aliasing > can timeout waiting on a single request using "alias.request"
	cypress/proxy-logging-spec.ts	1
1	Proxy Logging > request logging > xhr log has response body/status code

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

kuceb · 2021-06-23T14:57:45Z

This might make migration to the new cypress.js (with plugins support) more difficult, causing users to do two config migrations back-to-back. Especially if we end up going with cypress.config.js. thoughts @cowboy @mccataldo ?

elevatebart · 2021-06-23T15:03:20Z

@bkucera I agree 💯

I will change cypress.js into cypress.config.js
There is no plan to merge this in cypress 8 (yet) only to merge it in the unified-desktop-gui branch, probably delivered in v9
This change is non-breaking and does not involve the deprecation of anything

I am sorry for the initial confusion

chrisbreiding · 2021-06-23T15:08:54Z

I share the concern that Ben mentioned. It might be more confusing to introduce one way of writing cypress.config.js and then another way than just to introduce the final way.

Also, a reason for utilizing the plugins file architecture for cypress.config.js is that it's contained in a child process and has more robust error handling. If there's an asynchronous error in this implementation of cypress.config.js, Cypress will crash. With the plugins file architecture, it would display an appropriately tailored error message.

There is no plan to merge this in cypress 8 (yet)

What is the plan for releasing this?

cowboy · 2021-06-23T19:54:21Z

This might make migration to the new cypress.js (with plugins support) more difficult, causing users to do two config migrations back-to-back. Especially if we end up going with cypress.config.js. thoughts @cowboy @mccataldo ?

I think it would be wise to coordinate any proposed changes to cypress.json -> cypress.js so that we can minimize the number of changes we need to communicate to our users. It may be wise to hold off on merging this for the moment until we can understand if there will be other changes needed. And we definitely need to make sure that we agree on the name!

jennifer-shehane · 2021-06-23T20:24:37Z

I'm also not understanding the purpose behind this change if it is not meant to be user facing before we make the changes to include plugin functionality to cypress.js. I read all of the Jira stories and the entire Notion doc and didn't see this as a step where we were headed. I may have missed it though.

lmiller1990

Left some questions, but looks pretty solid!

lmiller1990 · 2021-06-29T07:29:20Z

npm/vue/cypress.config.js

@@ -0,0 +1,32 @@
+const { startDevServer } = require('@cypress/webpack-dev-server')


Cool, in future we should try to use git mv to preserve the history. It will also make the PR smaller to review.

In theory yes, but have you seen it actually work?

Usually, but I had an experience recently where it did not - seems if you change too many LOC in the file, it doesn't work. Not really a big deal, but good to keep in mind.

lmiller1990 · 2021-06-29T07:31:41Z

npm/vue/cypress.config.js

+ projectId: '134ej7',
+ testFiles: '**/*spec.js',
+ experimentalFetchPolyfill: true,
+ component: (on, config) => {


If we want to customize some values for component, eg viewport, what is the recommendation?

Before

{ "component": { "viewportHeight": 400 } }

After

module.exports = { component: (on, config) => { // ... return { ...config, viewportHeight: 400 } } }

Is this correct? For anyone with overrides, the migration won't be as simple as rename + wrap in module.exports. We might want to include this in the PR description and (eventual) docs.

I think this is how it was intended indeed.

This or a simple affectation (no need for the spread)

module.exports = { component: (on, config) => { // ... config.viewportHeight = 400 return config } }

packages/server/test/cache_helper.js

packages/server/test/unit/project_spec.js

jennifer-shehane

Nice work. Just mentioning a few edge cases I found. I didn't really test too extensively. I'm not sure if all of these issues are something that need addressing now or if you want to make separate tickets for future work.

Crash

I had Cypress crash at one point when I was editing the cypress.config.js file and now I can't reproduce it. 😞 There was no error in the stdout when it happened.

Export empty obj

If you export an empty object for the cypress.config.js file with a cypress.json file present - it sees this as if the cypress.config.js has been deleted completely and a misleading error displays. This should be supported and is likely the large majority of cases of how I see people would start the file when migrating.

module.exports = {}

nonexistent configFile

If I pass a nonexistent --config-file via cypress open, there's a pretty confusing error that displays in the GUI. The previous behavior was that it created a new file at the location. I actually don't remember that being the behavior or if that's what we want to continue doing.

Additionally when I click to 'Try again' on this screen (still with the nonexistent file), Cypress gets stuck in a loading spinner and clicking into the other tabs just blank out - have to restart Cypress.

Settings

The Settings tab is pretty wonky.

e2e shows as null even though I have a function set

These extra values are showing

These values don't show in 7.6.0.

configFile should show as relative path

The instructions for where to put projectId need updating

Also Node.js instructions need updating

projectId

I'm curious on what would happen if someone exportts a different projectId for e2e versus component - will need to be considered and tested as I imagine someone would try to set up 2 different projects in the Dashboard.

jennifer-shehane · 2021-06-29T16:05:36Z

packages/driver/cypress/integration/commands/request_spec.js

@@ -830,7 +830,7 @@ describe('src/cy/commands/request', () => {
 expect(this.logs.length).to.eq(1)
 expect(lastLog.get('error')).to.eq(err)
 expect(lastLog.get('state')).to.eq('failed')
- expect(err.message).to.eq('`cy.request()` must be provided a fully qualified `url` - one that begins with `http`. By default `cy.request()` will use either the current window\'s origin or the `baseUrl` in `cypress.json`. Neither of those values were present.')
+ expect(err.message).to.eq('`cy.request()` must be provided a fully qualified `url` - one that begins with `http`. By default `cy.request()` will use either the current window\'s origin or the `baseUrl` in `cypress.config.js`. Neither of those values were present.')


This error is slightly inaccurate since the baseUrl could have been passed via the --config outside of the configuration file. But, I know this wasn't introduced in this PR. 😝

I fixed the error message to say option instead of the file, since it can com from either configfile or the CLI options but is most likely something wrong within the test.

jennifer-shehane · 2021-06-29T16:58:14Z

Ah! I also saw this error in CI when building locally. I reran the build and it passed the next time, so doesn't seem isolated to CI.

elevatebart · 2021-06-29T20:30:41Z

@jennifer-shehane this one is on the main branch too I believe. It is linked to the configuration of typescript. I fixed it in my last commit.

lmiller1990 · 2021-06-30T05:50:53Z

Great review above - can you tag me again when I should re-review this? Looks like you are still addressing some feedback and CI is red.

elevatebart · 2021-07-07T22:11:01Z

@jennifer-shehane thank you for the great review.

I fixed the error when a config file was missing or misnamed.
I also fixed the error when a change in config triggered a crash by closing and re-opening the current project.

I am very hesitant to fix the desktop-gui settings tab, since it will need a lot of re-design

What should I do with functions? (they cannot be transferred through ipc)
Is cypress.env.json still relevant?
Should we update the inline documentation twice? Once now, and once with the unified GUI?

[EDIT] Since we decided to merge this in 8.X, I did all the nececssary updates in the desktop-gui to avoid inconsistencies. The 3 points above are therefore irrelevant.

flotwig · 2021-08-18T17:50:07Z

@lmiller1990

New module not detected

1. make config file

export default {
  "projectId": "ypt4pf",
  "baseUrl": "http://localhost:3500",
  viewportHeight: 700,
  "retries": {
    "runMode": 2,
    "openMode": 0
  }
}

1. open desktop gui

2. add `random.ts` with:

export const height = 999

1. update `cypress.config.ts`:

import { height } from "./random";

export default {
  "projectId": "ypt4pf",
  "baseUrl": "http://localhost:3500",
  viewportWidth: height,
  viewportHeight: 700,
  "retries": {
    "runMode": 2,
    "openMode": 0
  }
}

Desktop GUI won't refresh. Not sure if we can solve this or not, or if it's really a big deal.

This code is supposed to watch the config file and reload if it or any required files change, I believe? This seems like a bug:

cypress/packages/server/lib/project-base.ts

Lines 559 to 561 in 69ebdba

 if (configFile !== false) { 

 this.watchers.watchTree(settings.pathToConfigFile(projectRoot, { configFile }), obj) 

 }

lmiller1990 · 2021-08-20T00:54:23Z

@flotwig the code you linked looks like it should be working. It's checking if configFile is not false, and watching it. I wonder if that was added after I raised the bug and is supposed to fix it. I'll have to give this another test, to see if it's been fixed or not, since @elevatebart is out for a while.

jennifer-shehane

Transfering the npm directories to the new cypress.config.js should be done in a separate PR considering this is not a breaking change. It's best to keep the PR to be the bare minimum required for the feature. The PR is already very large and it would help get a faster review since this requires every member of the team to review. Also any refactors like the markdown-renderer refactor should be in a separate PR.

I've left comments within the code for review. Please expand all hidden comments, there is a lot.

Outside of those, some observations while manually testing:

When the error is shown about duplicate config, the loading spinner for the projects area is still shown and spinning.
Can we reword this message instead of saying 'retry again' to explicitly tell them what to do.

Please remove one of the two, quit and relaunch Cypress.
So I just pasted the JSON from the cypress.json file directly into the cypress.config.js file, because I kind of expect people to just do this without reading any of the migration guide and I get this error. I'm not sure if the error here can be better. Is there a way to detect that they just have JSON in the file and explain to them that if it's pure JSON that they need to migrate to export, etc - link to migration guide?
When I added the export as shown in the PR description, I got this error about unexpected token, 'export'.
Then I tried to switch to the defineConfig method I'd seen in the config.ts in this repo and it throws an error again. I guess my bit of takeaway from this is that these error messages are not helpful at all. They should say something like:

There's an error in your config file at the following location: ...
Make sure that your config file is structured like this:
...minimum required code structure for file....
link to guide where it explains how to write in config file.

And secondly apparently I have no idea how to write this config file because this PR description is not up to date. Please keep the PR description up to date so people can find the proper documentation to fully review without having to search through outside resources.

<img width="515" alt="Screen Shot 2021-08-24 at 10 29 33 AM" src="https://user-images.githubusercontent.com/1271364/130645482-10513f7e-f090-4778-bfad-cc303d24bda8.png">

<img width="798" alt="Screen Shot 2021-08-24 at 10 30 17 AM" src="https://user-images.githubusercontent.com/1271364/130645572-b17a8f2a-3a60-4c82-b0a6-c35815404194.png">

Was just thinking through another case where the cypress.json and cypress.config.js will co-exist together. If someone runs Cypress on 8.x (where cypress.config.js is scaffolded), then quickly runs Cypress on 8.3.0 to test some change in the update, it will scaffold the cypress.json back again. May be annoying for a few people trying to track down some regression for it to scaffold a diff file for each back and forth.

packages/server/lib/errors.js

jennifer-shehane · 2021-08-19T13:56:04Z

packages/server/lib/errors.js

+ // TODO: update with vetted cypress language
+ case 'CT_NO_DEV_START_FUNCTION':
+ return stripIndent`\
+ To run component-testing, cypress needs the \`setupDevServer\` function to be implemented. 


Suggested change

To run component-testing, cypress needs the \`setupDevServer\` function to be implemented.

To run component-testing, the \`setupDevServer\` function needs to be implemented.

jennifer-shehane · 2021-08-19T13:56:19Z

packages/server/lib/errors.js

+ return stripIndent`\
+ To run component-testing, cypress needs the \`setupDevServer\` function to be implemented. 
+
+ Add a \`setupDevServer()\` in the component object of the ${arg1} file.


Suggested change

Add a \`setupDevServer()\` in the component object of the ${arg1} file.

Add a \`setupDevServer()\` in the `component` object of the ${arg1} file.

packages/server/lib/errors.js

jennifer-shehane · 2021-08-19T14:06:20Z

cli/types/cypress.d.ts

@@ -2582,6 +2594,7 @@ declare namespace Cypress {
 /**
 * If set to `system`, Cypress will try to find a `node` executable on your path to use when executing your plugins. Otherwise, Cypress will use the Node version bundled with Cypress.
 * @default "bundled"
+ * @deprecated nodeVersion will soon be fixed to "system" to avoid confusion


I don't think this sufficiently explains the reasoning for the move and would rather avoid putting a short description that is not all encompassing of the reasons.

Suggested change

* @deprecated nodeVersion will soon be fixed to "system" to avoid confusion

* @deprecated nodeVersion will soon be fixed to "system"

jennifer-shehane · 2021-08-19T16:50:12Z

packages/server/lib/project-base.ts

+ if (typeof cfg.configFile === 'string'
+ && /\.json$/.test(cfg.configFile)


Suggested change

if (typeof cfg.configFile === 'string'

&& /\.json$/.test(cfg.configFile)

const = isJsonFile = (filename) => {

return /\.json$/.test(cfg.configFile)

}

if (typeof cfg.configFile === 'string'

&& isJsonFile(cfg.configFile)

jennifer-shehane · 2021-08-19T16:50:24Z

packages/server/lib/project-base.ts

 process.chdir(this.projectRoot)

 // TODO: we currently always scaffold the plugins file
 // even when headlessly or else it will cause an error when
 // we try to load it and it's not there. We must do this here
 // else initialing the plugins will instantly fail.
- if (cfg.pluginsFile) {
+ if (cfg.pluginsFile && (!cfg.configFile || /\.json$/.test(cfg.configFile))) {


Suggested change

if (cfg.pluginsFile && (!cfg.configFile || /\.json$/.test(cfg.configFile))) {

if (cfg.pluginsFile && (!cfg.configFile || isJsonFile(cfg.configFile))) {

jennifer-shehane · 2021-08-19T16:57:04Z

packages/server/lib/util/settings.js

 // we cannot write due to folder permissions
 return errors.warning('FOLDER_NOT_WRITABLE', projectRoot)
 }).catch((err) => {
 if (errors.isCypressErr(err)) {
+ debug('throwing error')


Suggested change

debug('throwing error')

debug('error thrown when seeing if find out if "%s" exists', file)

jennifer-shehane · 2021-08-19T16:57:28Z

packages/server/lib/util/settings.js

- }).catch({ code: 'EACCES' }, { code: 'EPERM' }, () => {
+ return this._err('CONFIG_FILE_NOT_FOUND', this.configFile(projectRoot, options), projectRoot)
+ }).catch({ code: 'EACCES' }, () => {
+ debug('no access error')


Suggested change

debug('no access error')

debug('no access error for "%s"', file)

jennifer-shehane · 2021-08-19T17:02:16Z

packages/server/lib/util/settings.js

@@ -196,7 +288,9 @@ module.exports = {
 return Promise.resolve({})
 }

- return this.read(projectRoot)
+ debug('write a file')


You need to think about these debug logs being logged alongside thousands of logs. It's helpful to be descriptive for support later to search/find the exact place where this debug log is. 'write a file' is too generic imo.

Suggested change

debug('write a file')

debug('write a new configuration file')

lmiller1990 · 2021-08-27T02:16:38Z

Thanks for the review @jennifer-shehane. Agree on keeping this one as minimal as possible.

Since Bart is away I'll raise this in our team and someone else will pick it up.

elevatebart · 2021-08-31T10:17:44Z

Thank you @jennifer-shehane
@lmiller1990 is right, great review once again.

Two details I wanted whomever is taking over the pull request need to know:

I did the migration of npm packages in this PR to use them as end to end tests. The PR is already humongous, so tried to make it complete and coherent. If we add these tests in a separate PR, it will be more work for all of us.
The failure on the export default is actually an issue in ts-node. When TypeScript is installed, one cannot have a cypress.config.js file using export default. This file has to use module.exports = . The team at ts-node are still working on it but want to avoid breaking changes as much as possible. Should we make it a clearer failure? Should we wait for their fix?

chrisbreiding

Jennifer and Lachlan did pretty thorough reviews, so I don't have too much to add besides some nitpicks.

chrisbreiding · 2021-08-31T13:49:30Z

packages/server/lib/util/require_async_child.js

@@ -0,0 +1,76 @@
+require('graceful-fs').gracefulify(require('fs'))
+const debug = require('debug')('cypress:server:require_async:child')


Should be possible for this to be TS. If CYPRESS_INTERNAL_ENV === 'development', utilize @packages/ts/register.js when spawning the child process (example here). Otherwise, for production, tsc the TS files and ship JS files in the binary, same as we do for the test of the TS files.

chrisbreiding · 2021-08-31T13:57:11Z

packages/server/test/unit/plugins/util_spec.js

@@ -55,6 +55,115 @@ describe('lib/plugins/util', () => {

 expect(handler).not.to.be.called
 })
+
+ context('#arguments-serialization', () => {


Suggested change

context('#arguments-serialization', () => {

context('argument serialization', () => {

# is meant to denote a method. It's not needed if it's a more generic suite title.

chrisbreiding · 2021-08-31T13:57:26Z

packages/server/test/unit/plugins/util_spec.js

+ })
+ })
+
+ context('#arguments-deserialization', () => {


Suggested change

context('#arguments-deserialization', () => {

context('argument deserialization', () => {

chrisbreiding · 2021-08-31T13:59:35Z

packages/server/test/unit/plugins/util_spec.js

@@ -55,6 +55,115 @@ describe('lib/plugins/util', () => {

 expect(handler).not.to.be.called
 })
+
+ context('#arguments-serialization', () => {
+ it('#send should send functions arguments as a serialized string', function () {


Seeing all these tests prefixed with #send indicates they could be moved into a describe called #send, then the test title is specific to what's unique about that test.

Also, it's not necessary to write "should" in every test title. It becomes redundant.

chrisbreiding · 2021-08-31T14:00:32Z

packages/server/test/unit/plugins/util_spec.js

+ })
+
+ context('#arguments-deserialization', () => {
+ it('#on should deserialise function strings into function', function () {


Same as with #send, #on should be moved out into a describe.

Co-authored-by: Jennifer Shehane <jennifer@cypress.io>

elevatebart requested a review from a team as a code owner June 17, 2021 22:41

elevatebart requested review from chrisbreiding and kuceb and removed request for a team June 17, 2021 22:41

lmiller1990 self-requested a review June 17, 2021 23:40

elevatebart marked this pull request as draft June 23, 2021 22:40

elevatebart changed the title ~~feat: make cypress.js available~~ feat: make cypress.config.js available Jun 24, 2021

elevatebart marked this pull request as ready for review June 28, 2021 22:16

lmiller1990 reviewed Jun 29, 2021

View reviewed changes

jennifer-shehane requested changes Jun 29, 2021

View reviewed changes

lmiller1990 mentioned this pull request Jul 8, 2021

feat: support ct/e2e specific overrides in cypress.json #15444

Merged

4 tasks

elevatebart added 8 commits July 9, 2021 08:57

feat: make cypress.js available

703b848

test: test cypress.js

e3ee515

clear cache after each test

7344f15

test: mock configFile resolve

3a57ee1

test: mock fs instead of settings

b55ecc0

test: mock fs and fix setup

714311a

test: cleanup cypress.json

00cb9bd

add unit tests for cypress js loading

584fe63

jennifer-shehane requested a review from flotwig August 16, 2021 14:35

jennifer-shehane requested changes Aug 24, 2021

View reviewed changes

lmiller1990 mentioned this pull request Aug 30, 2021

feat(launchpad): detect if runner is set up and change UI accordingly #17934

Merged

Merge branch 'develop' into feat/allow-cypress-js

a46f367

chrisbreiding requested changes Aug 31, 2021

View reviewed changes

jennifer-shehane mentioned this pull request Sep 8, 2021

Cypress config files should support "extends" option #5674

Closed

elevatebart and others added 6 commits September 9, 2021 14:13

refactor: rename option setupDevServer

b998201

Merge branch 'develop' into feat/allow-cypress-js

c608a9e

chore: error wording changes

4789731

Co-authored-by: Jennifer Shehane <jennifer@cypress.io>

chore: update error wording

7bcafa0

Co-authored-by: Jennifer Shehane <jennifer@cypress.io>

fix: reword unit test title in server settings

07be3c4

fix: build process

49f97eb

elevatebart mentioned this pull request Sep 10, 2021

feat: allow use of javascript in config file #18061

Merged

1 task

elevatebart and others added 9 commits October 1, 2021 11:05

build: make build artifacts on this PR branch

4cdef63

Merge branch 'develop' into feat/allow-cypress-js

27597fc

Merge branch 'develop' into feat/allow-cypress-js

2fb6862

make build pass

38a9a27

fix types missing

61a2f58

fix changed types

d44aada

fix vite too

f94d433

fix build process on darwin

241b096

fix the build

a120c2c

elevatebart marked this pull request as draft November 8, 2021 15:06

elevatebart closed this Nov 8, 2021

smccarthy-godaddy mentioned this pull request Mar 7, 2022

Proposal: allow configuration file to be 'js', not 'json' #5218

Closed

elevatebart deleted the feat/allow-cypress-js branch March 24, 2022 18:19

		@@ -0,0 +1,32 @@
		const { startDevServer } = require('@cypress/webpack-dev-server')

	To run component-testing, cypress needs the \`setupDevServer\` function to be implemented.
	To run component-testing, the \`setupDevServer\` function needs to be implemented.

	Add a \`setupDevServer()\` in the component object of the ${arg1} file.
	Add a \`setupDevServer()\` in the `component` object of the ${arg1} file.

	* @deprecated nodeVersion will soon be fixed to "system" to avoid confusion
	* @deprecated nodeVersion will soon be fixed to "system"

		if (typeof cfg.configFile === 'string'
		&& /\.json$/.test(cfg.configFile)

	if (cfg.pluginsFile && (!cfg.configFile \|\| /\.json$/.test(cfg.configFile))) {
	if (cfg.pluginsFile && (!cfg.configFile \|\| isJsonFile(cfg.configFile))) {

	debug('throwing error')
	debug('error thrown when seeing if find out if "%s" exists', file)

	debug('no access error')
	debug('no access error for "%s"', file)

	debug('write a file')
	debug('write a new configuration file')

		@@ -0,0 +1,76 @@
		require('graceful-fs').gracefulify(require('fs'))
		const debug = require('debug')('cypress:server:require_async:child')

	context('#arguments-serialization', () => {
	context('argument serialization', () => {

	context('#arguments-deserialization', () => {
	context('argument deserialization', () => {

feat: make cypress.config.js available #17000

feat: make cypress.config.js available #17000

Conversation

elevatebart commented Jun 17, 2021 • edited Loading

Summary

cypress.json cypress.config.ts

Default config file

Creating missing file

Plugins definition functions

Technical implementation

defineConfig()

desktop-gui

Deprecation warnings

To see the desktop warning:

To see the warning in the component testing runner

Technical detail

Remaining work before merge

cypress-bot bot commented Jun 17, 2021

cypress bot commented Jun 22, 2021 • edited Loading

Test summary

Run details

Flakiness

kuceb commented Jun 23, 2021

elevatebart commented Jun 23, 2021 • edited Loading

chrisbreiding commented Jun 23, 2021

cowboy commented Jun 23, 2021

jennifer-shehane commented Jun 23, 2021

lmiller1990 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Before

After

Choose a reason for hiding this comment

jennifer-shehane left a comment

Choose a reason for hiding this comment

Crash

Export empty obj

nonexistent configFile

Settings

e2e shows as null even though I have a function set

These extra values are showing

configFile should show as relative path

The instructions for where to put projectId need updating

Also Node.js instructions need updating

projectId

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jennifer-shehane commented Jun 29, 2021

elevatebart commented Jun 29, 2021

lmiller1990 commented Jun 30, 2021

elevatebart commented Jul 7, 2021 • edited Loading

flotwig commented Aug 18, 2021

New module not detected

lmiller1990 commented Aug 20, 2021

jennifer-shehane left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lmiller1990 commented Aug 27, 2021

elevatebart commented Aug 31, 2021

chrisbreiding left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

elevatebart commented Jun 17, 2021 •

edited

Loading

cypress bot commented Jun 22, 2021 •

edited

Loading

elevatebart commented Jun 23, 2021 •

edited

Loading

elevatebart commented Jul 7, 2021 •

edited

Loading