-
Notifications
You must be signed in to change notification settings - Fork 3.3k
fix: detect newly added specs in dev-server compilation #17950
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
Conversation
Thanks for taking the time to open a PR!
|
npm/webpack-dev-server/src/loader.ts
Outdated
@@ -49,7 +50,11 @@ function buildSpecs (projectRoot: string, files: Cypress.Cypress['spec'][] = []) | |||
} | |||
|
|||
// Runs the tests inside the iframe | |||
export default function loader (this: CypressCTWebpackContext) { | |||
export default function loader (this: CypressCTWebpackContext & LoaderContext<any>) { |
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.
Don't you want unknown
? CC @lmiller1990
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.
I think we want <void>
, we are intentionally not passing any additional options to the loader context.
I am not entirely clear on how this generic is used, but you rarely, if ever, want any
(unless it's truly valid that your function can take any argument, which is pretty unusual).
This test might be close to what we need: https://github.com/cypress-io/cypress/blob/develop/npm/webpack-dev-server/test/e2e.spec.ts#L131 Basically when we make a new file, we want to ensure that webpack re-runs and emits the right event - that looks like what this test is doing. I tested this and it works great! I notice this message: "Not cacheable". I wonder if there's any perf implications. |
// In Webpack 5, a spec added after the dev-server is created won't | ||
// be included in the compilation. Disabling the caching of this loader ensures | ||
// we regenerate our specs and include any new ones in the compilation. | ||
this.cacheable(false) |
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.
Do we want this to be conditional (if we are using Webpack 5)? Does this.cacheable
even exist in Webpack 4?
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.
It won't throw even if it doesn't. I'm fine with this.
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.
this.cacheable
is valid for Webpack 4 and 5
https://v4.webpack.js.org/api/loaders/#thiscacheable
@lmiller1990 I was able to get some performance metrics after looking into #17920. Here is what I found testing inside a Next repo using Webpack 5:
"Cold start" was the time it took for Webpack to when running Adding the cache: false option to the webpack.config.js fixes the spec detection issue but at a high performance cost. |
1f20c0b
to
8a1e6d4
Compare
Great! Still in draft - any outstanding changes @ZachJW34 and can we merge? |
@lmiller1990 Looks like you tagged the wrong Zach :) Think you were looking for @ZachJW34 |
@Zacharias3690 updated tagging the correct person... sorry about that! 🤦 |
@lmiller1990 fixed the tests by adding |
* develop: feat: gray out the path to system node in cypress run header (#20121) feat: redesign server errors (#20072) test: fix awesome-typescript-loader test and remove test-binary job (#20131) fix: Fix issues with stack traces and command log in Chrome 99 (#20049) fix: `cy.type(' ')` fires click event on button-like elements. (#20067) fix: `change`, `input` events are not fired when the same option is selected again. (#19623) build: publish vue3 on latest (#20099) chore: release @cypress/webpack-preprocessor-v5.11.1 chore: release @cypress/webpack-dev-server-v1.8.1 fix: detect newly added specs in dev-server compilation (#17950) chore: Remove pkg/driver //@ts-nocheck part 3 (#19837) chore: set up semantic-pull-request GitHub Action (#20091) chore: release @cypress/react-v5.12.2 fix: remove nullish coalescing in js files to support node 12 (#20094) docs: update @cypress/webpack-preprocessor links (#19902) refactor: use aliases instead of meta (#19566)
User facing changelog
Additional details
There are more fine-grained API's for controlling loaders. I tried a few, such as
addDependency
andaddContextDependency
without much luck. This loader is pretty cheap so I don't think disabling the caching would have much of a performance hit. Also, I still need to write a test covering this case.How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?cypress.schema.json
?