chore: vite-dev-server refactor to enable version bumps and testing vite core perf improvements #20532
Conversation
|
Thanks for taking the time to open a PR!
|
|
Test summary
Run details
View run in Cypress Dashboard ➡️ Flakiness
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 |
||||||||||||||||||||||||||
| "@vue/compiler-core": "3.2.31", | ||
| "@vue/compiler-dom": "3.2.31", | ||
| "@vue/compiler-sfc": "3.2.31", | ||
| "@vueuse/core": "7.2.2", | ||
| "@windicss/plugin-interaction-variants": "1.0.0", | ||
| "ansi-to-html": "0.6.14", |
There was a problem hiding this comment.
A lot of new packages added here - some of them removed from the launchpad package.json, others added here (and still there). Is this just general cleanup, making sure things are required in the right place?
There was a problem hiding this comment.
A lot of these are legitimate, but there's a few that leaked in while debugging a frontend-shared-only failure
There was a problem hiding this comment.
K. Removed the few of them that were accidentally added. A lot of the additions were just missing dependencies, and Vite was somehow resolving them in other ways.
… into chore/vite-dev-server
| server: { | ||
| fs: { | ||
| // Since we're in a monorepo, we're going to serve packages from | ||
| // npm/vue/dist/* and other local places. This enables us to do that. | ||
| // https://vitejs.dev/config/#server-fs-strict | ||
| strict: false, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
This is the only thing I don't like. We talked about it. That could probably be flagged as a security threat.
Scope
This PR bumps versions for Vite and associated plugins. It's required so that we can test out if alpha Vite builds will fix the issues we're experiencing in our own repository.
This PR does not fix any run-only issues. If there is new flakiness that was introduced in Vite 2.8.4, we'll need to continue with the "build" improvements approach instead of merging this PR in directly.