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: add next preset to webpack-dev-server-fresh #21069

Merged
merged 10 commits into from Apr 19, 2022

Conversation

ZachJW34
Copy link
Contributor

User facing changelog

Add next support for new Object API in webpack-dev-server-fresh

Additional details

Mostly a lift and shift from npm/react/plugins for next specific webpack code. Since Next ships it's own version of webpack, I had to change how we source webpack deps to account for this. The most notable change is the removal of Next v10 support which is two major versions behind the current Next v12. I also changed how we detect if swc is being used. It was accounting for the possibility of being used on 9.x but we don't have that requirement for the new packages.

How has the user experience changed?

Screen.Recording.2022-04-13.at.12.13.54.PM.mov

PR Tasks

  • Have tests been added/updated?
  • Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
  • Has a PR for user-facing changes been opened in cypress-documentation?
  • Have API changes been updated in the type definitions?
  • Have new configuration options been added to the cypress.schema.json?

@ZachJW34 ZachJW34 requested review from a team as code owners April 13, 2022 17:16
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Apr 13, 2022

Thanks for taking the time to open a PR!

@ZachJW34 ZachJW34 requested review from jennifer-shehane, tgriesser, BlueWinds and lmiller1990 and removed request for a team April 13, 2022 17:16
@cypress
Copy link

cypress bot commented Apr 13, 2022



Test summary

17881 0 217 0Flakiness 1


Run details

Project cypress
Status Passed
Commit c521e1c
Started Apr 19, 2022 10:14 PM
Ended Apr 19, 2022 10:28 PM
Duration 14:13 💡
OS Linux Debian - 10.10
Browser Multiple

View run in Cypress Dashboard ➡️


Flakiness

cypress/e2e/commands/xhr.cy.js Flakiness
1 ... > no status when request isnt forced 404

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

@jennifer-shehane jennifer-shehane removed their request for review April 13, 2022 18:02
@ZachJW34
Copy link
Contributor Author

Need to update the fixture with the new data-cy-root selector.

Copy link
Contributor

@lmiller1990 lmiller1990 left a comment

Choose a reason for hiding this comment

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

Code seems fine and tests pass - I think some comments might be useful, considering how many different branches there are for the next.js handler.

Support for next@latest is awesome and a must have, great to see this 🚀

return pagesDir
}

pagesDir = path.join(projectRoot, 'src/pages')
Copy link
Contributor

Choose a reason for hiding this comment

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

Should it be path.join(projectRoot, 'src', 'pages') to use the correct separator on windows?

let webpack5 = true
const importPath = path.dirname(webpackJsonPath)
const webpackModule = require(path.join(importPath, 'webpack.js'))

Copy link
Contributor

Choose a reason for hiding this comment

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

This entire webpack module file is getting to be really complex really fast, I wonder if we can find some cleaner way to handle this eventually...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree, @tgriesser might have some good ideas on cleaning this up. I think we should allow the handlers to source the information so we don't have the framework bloat in this file, and sourceRelativeWebpackModules.ts could be helper functions that the handlers consume, but not going to refactor in this PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed, this stuff is all super ugly. It makes me want to have a next-dev-server separate from our webpack-dev-server, since it's requiring so much custom configuration / patching.

Copy link
Contributor

Choose a reason for hiding this comment

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

Or at the very least its own file / function in webpack-dev-server. webpackConfig = framework === 'nextjs') ? getNextWebpackConfig() : getWebpackConfig(), and they can share utility functions as needed.

Copy link
Contributor

Choose a reason for hiding this comment

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

The more I look at it the more it feels like something we should decide now rather than later, pull it out in some fashion rather than kick it down the road.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm going to refactor this! I'm sidetracked getting the dev-servers to work with the built binary but going to return

Copy link
Member

Choose a reason for hiding this comment

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

Yeah I think the next stuff should be handled separately than the regular one.

The first attempt here was intentionally procedural, until we knew what we needed to reuse for next, it didn’t make sense to abstract.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Refactored, broke the functions up so they could be reused and altered the handler contract so that each handler is responsible for providing the sourced deps.

const debug = debugLib('cypress:webpack-dev-server-fresh:nextHandler')

export async function nextHandler ({ devServerConfig, sourceWebpackModulesResult }: PresetHandler) {
const webpackConfig = await loadWebpackConfig({ devServerConfig, sourceWebpackModulesResult })
Copy link
Contributor

Choose a reason for hiding this comment

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

This look really thorough, nice job -- it's a little challenging to fully understand what case each branch handles, might be a good candidate for some fairly verbose comments?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added some more comments throughout

@@ -137,6 +138,10 @@ devServer.create = async function (devServerConfig: WebpackDevServerConfig) {
case 'vue-cli':
frameworkConfig = vueCliHandler({ devServerConfig, sourceWebpackModulesResult })
break

Copy link
Contributor

Choose a reason for hiding this comment

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

Just a style thing, with big switch statements like this, I always prefer having them out in their own function, so you can just return from each branch, a'la

getConfig = async (framework) => {
  switch (framework) {
    case 'react':
      return
    case 'nuxt':
      return await nuxtHandler({ devServerConfig, sourceWebpackModulesResult })
    ...etc...
  }
}

let frameworkConfig = await getConfig(devServerConfig.framework)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed in ac29f02

}

/**
* Acquire the modules needed to load the Next webpack config
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not really following this comment. Acquire them how, for what, why, from where?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed in ac29f02

let webpack5 = true
const importPath = path.dirname(webpackJsonPath)
const webpackModule = require(path.join(importPath, 'webpack.js'))

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed, this stuff is all super ugly. It makes me want to have a next-dev-server separate from our webpack-dev-server, since it's requiring so much custom configuration / patching.

let webpack5 = true
const importPath = path.dirname(webpackJsonPath)
const webpackModule = require(path.join(importPath, 'webpack.js'))

Copy link
Contributor

Choose a reason for hiding this comment

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

Or at the very least its own file / function in webpack-dev-server. webpackConfig = framework === 'nextjs') ? getNextWebpackConfig() : getWebpackConfig(), and they can share utility functions as needed.

let webpack5 = true
const importPath = path.dirname(webpackJsonPath)
const webpackModule = require(path.join(importPath, 'webpack.js'))

Copy link
Contributor

Choose a reason for hiding this comment

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

The more I look at it the more it feels like something we should decide now rather than later, pull it out in some fashion rather than kick it down the road.

@ZachJW34 ZachJW34 requested a review from BlueWinds April 18, 2022 15:04
Copy link
Contributor

@lmiller1990 lmiller1990 left a comment

Choose a reason for hiding this comment

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

One comment around unnecessary await.

Any other blocker? Let's get this merged CT Arch and this PR should be #1 priority.

return await nuxtHandler(devServerConfig)

case 'vue-cli':
return await vueCliHandler(devServerConfig)
Copy link
Contributor

Choose a reason for hiding this comment

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

No need `await here.

Copy link
Member

Choose a reason for hiding this comment

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

Updated

@ZachJW34 ZachJW34 merged commit ccfee1e into 10.0-release Apr 19, 2022
@ZachJW34 ZachJW34 deleted the zachw/next-preset branch April 19, 2022 22:52
tgriesser added a commit that referenced this pull request Apr 20, 2022
…e-config

* 10.0-release:
  chore: Move component-index generation to scaffold-config package (#21090)
  fix: label text should be clickable to toggle snapshot highlight (#21122)
  feat: add next preset to webpack-dev-server-fresh (#21069)
  chore: add dev-servers as deps to server to be included in the binary (#21142)
  fix: do not highlight preExtension if selected option is renameFolder (#21121)
  fix(unify): Remove 'Reconfigure' dropdown from Testing Type chooser (#21063)
  feat(unify): launchpad header breadcrumbs and reusable tooltip component (#20648)
  test: add windows-test-kitchensink job (#20847)
  fix: aut centering and height calculation (#21019)
  chore: fix tests that fail on windows (#21055)
  fix: running a new test after already having run tests (#21087)
  fix: ct project setup framework keys for next and nuxt (#21116)
  fix: remove MountReturn from scaffolded ct support file (#21119)
  fix: do not scaffold fixtures if folder exist (#21078)
  fix: revert "fix: types for Cypress.Commands.add (#20376)" (#21104)
  chore: Update Chrome (stable) to 100.0.4896.127 and Chrome (beta) to 101.0.4951.34 (#21083)
  fix: types for Cypress.Commands.add (#20376) (#20377)
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

4 participants