refactor: remove build time pre-bundling #15184
Conversation
|
|
patak-dev
added
p2-nice-to-have
|
I don't know why the docs are failing in netlify, they are building correctly locally. |
| test.runIf(!isBuild)('message from require-external-cjs', async () => { | ||
| await page.goto(url) | ||
| expect(await page.textContent('.require-external-cjs')).toMatch('foo') | ||
| }) |
There was a problem hiding this comment.
@sapphi-red I had to skip this test during build. It seems it only works with deps optimization during build.
There was a problem hiding this comment.
👍 I think it's fine for now. To make this work, we'll need to convert import foo from 'foo' into import module from 'node:module'; const foo = module.createRequire(import.meta.url)('foo') in this case.
|
this could break vite-plugin-svelte, which checks optimizeDeps.disabled but doesn't know about optimizeDeps.noDiscovery. If i understand it correctly noDiscovery isn't the same as disabled. noDiscovery prevents the auto-scanner, but user config/plugins like v-p-s would still be able to add to optimizeDeps.include. whereas disabled=true would turn it off completely. The documentation here https://vitejs.dev/config/dep-optimization-options.html#optimizedeps-disabled only mentions that optimizing in build mode is experimental, not that optimizeDeps.disabled as a flag itself is. So to not break, i suggest to keep the disabled option, but change it so that false/'dev' log a warning that they are no longer supported. and with 6.0 we can change it to |
|
/ecosystem-ci run vite-plugin-svelte |
|
📝 Ran ecosystem CI on
|
|
Edit: fixed in tsx, install [email protected] For docs, you can set NODE_VERSION to 20 in netlify.toml. Node v18.19 changed some stuff about loaders that's breaking tsx. Created an issue upstream - privatenumber/tsx#421 |
|
/ecosystem-ci run |
|
5da3702 brings back
Just for reference, both the docs and the types have |
|
📝 Ran ecosystem CI on
|
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
/ecosystem-ci run vite-setup-catalogue |
|
📝 Ran ecosystem CI on
|
| // When we use the Rollup CommonJS plugin instead of esbuild prebundling, | ||
| // the esbuild plugins won't apply to dependencies | ||
| test('esbuild-plugin', async () => { | ||
| test.runIf(isServe)('esbuild-plugin', async () => { |
There was a problem hiding this comment.
I really appreciate your work, but I have some feedback I'd like to share. There are some custom esbuild plugins in my app to handle special files in dependencies, as described in docs. If the pre-build feature is removed at build time, is there any other way to keep the custom esbuild plugin consistent in build mode?
There was a problem hiding this comment.
You'll need to have the same custom handling implemented as a rollup plugin. It would be good if you link to the way you are using it for reference, but I think it would be hard to justify the complexity this PR is removing as it can be still make to work. And later on if we move to Rolldown instead of esbuild, then you will get the consistency back for dependency handling.
Closes #8464
Closes #9171
Closes #9549
Closes #13018
Closes #14106
Description
Starting from #8280, we added experimental support for build time deps optimization. An idea by Evan, that was originally proposed at #4921. The idea was sound, removing a big difference between dev and build (no
@rollup/plugin-commonjs, same esbuild pipeline for dependencies in both cases) and hopefully speeding up processing on warm builds (once deps were cached).In practice, the extra complexity of doing deps optimization at build time and added points of failures made this feature stay experimental until now, seeing little usage. We had issues with rollup not being able to correctly tree-shake dependendencies (that we probably could have solved eventually, but is a good example).
With Rollup 4 switching its parser to native, and Rolldown being worked on, both the performance and the dev-vs-build inconsistency story for this feature are no longer valid. If we want to focus on improving dev/build consistency, then using Rolldown for prebundling during dev and Rolldown as-is during build is a better bet moving forward. Rolldown may also implement caching in a way that is a lot more efficient during build than deps prebundling.
This PR removes the feature, and also removes
optimizeDeps.disabled: 'build' | 'dev' | booleanwith it. We now haveoptimizeDeps.noDiscovery. So the optimizer can be disabled by settingoptimizeDeps.noDiscovery: trueand leavingoptimizeDeps.includeempty.The PR keeps SSR deps optimization during dev. In this case,
ssr.optimizeDeps.noDiscoveryis alwaystrue, and the user must manually add deps to optimize tossr.optimizeDeps.include. When we added this feature, we madenoExternalauto-populatessr.optimizeDeps.include. This PR removes this heuristic, because it means we will need a new config option to disable the SSR dev optimizer and also forcedexcludeto work differently. Given thatnoExternal/externalmay also be reviewed later, it is better to keepincludeexplicit. The user can easily share the array if they would like allnoExternaldeps to be optimized. @bluwy raised the question if it is justified to keep deps optimization during SSR dev. The complexity is fairly low and it is useful to workaround some issues, so for now, it is kept in this PR. It is still experimental, so we can review and remove it later on too if that is desired.Related feedback discussions:
What is the purpose of this pull request?