-
Notifications
You must be signed in to change notification settings - Fork 496
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
perf: bundle runtime dependencies #1554
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1554 +/- ##
==========================================
+ Coverage 76.00% 76.20% +0.19%
==========================================
Files 74 76 +2
Lines 7711 7778 +67
Branches 760 773 +13
==========================================
+ Hits 5861 5927 +66
- Misses 1848 1849 +1
Partials 2 2
|
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.
In future we might need an opt out for major versions somehow? (If user, or other library is using dependency.)
Or equally if one of these is a dependency of an external we might have an issue too.
Co-authored-by: Daniel Roe <daniel@roe.dev>
Yes, i was thinking to support Regarding major versions (or any custom version by user), we still use rollup's search path, resolution, and aliases so overriding is possible by all means, however even totday, we require them (defined list) to be in Nitro-Expected semver-major range as nitro internally uses all these deps. (if an external dependency in I want to make sure mainly it is good to you too for becoming the default behavior . |
It is fine to me as default behaviour. I'm observing the potential issue that if a library in externals uses ufo/pathe then this will be included twice (once in node_modules and once bundled). If other major versions of libraries like ufo are included in externals that entirely addresses my first point. |
That's a valid point if both inline and external use same semver/major of ufo. And was initial reason that we made all externals by default. I guess we can think of some ways to automatically "deoptimize" inlining however it involves traced file dependency "pre-analysis" and sub-dependencny deptimization. I guess for default behavior, it should benefit most of users both Nitro and Nuxt with both bundle size but more importantly the stability of resolutions with rollup comparing to current externals. |
Yes, I see this as a good change, too. |
Updated: Sourcemap size issue is (kinda) resolved by using a sourcemap minify plugin that scans emited sourcemap chunks and dynamically disables the ones that include node modules (reducing basic build from I think there is way more area for improving this plugin. We can tree-shake content only for example. Considering we use lazy chunks for user code, this should be relatively ok. This can be disabled with
Merging to main to test against edge about effect of this change and fine-tune until release. |
π Linked issue
β Type of change
π Description
Nitro output uses file tracing for all node modules by default. It has many benefits such as supporting native modules and the best compatibility with minimized rollup involvement.
However, there are downsides with externals too at least for built-in and standard unjs packages inlining is better.
package.json
files are copied over the output directorynode_modules
resolutionAsyncLocalStorage
)This PR uses a list of nitro built-in runtime dependencies and explicitly inlines them in the final output bundle.
TODO: This method however has a downside in that inlined sourcemaps add to the bundle overhead. Looking for a way to disable inline-source maps only for node_modules.Benchmark Results
Config:
Timing bench:
Node.js version: v18.16.0 on Macbook Air M2
π Checklist