-
Notifications
You must be signed in to change notification settings - Fork 27.1k
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
Replace optionalDependencies with script for installing swc #33496
Conversation
This comment has been minimized.
This comment has been minimized.
Yarn berry has started working on the libc field in the package.json yarnpkg/berry#3981 |
@Brooooooklyn I'm curious if |
|
||
if (!activePackage) { | ||
// TODO: should this be a hard error even though it fails install? | ||
// should we fallback to wasm in this case? |
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.
Falling back to wasm makes sense to me.
Thats the advantage of this custom install script 👍
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.
Yeah, falling back to wasm sounds good to me.
|
||
try { | ||
await fetch( | ||
`https://registry.npmjs.org/${activePackage.packageName}/-/${tarFileName}` |
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.
Some setups don't have access to the npm registry so this will be problematic
Ref evanw/esbuild#1621
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.
Yeah this is problematic because package config like .npmrc
or .yarnrc
is no longer respected evanw/esbuild#286
Perhaps we need to double down on getting this feature into npm now that yarn just landed it in yarnpkg/berry#3981
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.
We can definitely handle loading the registry from the package config. I think it's gonna be a while before this is sorted out/performant in relevant package managers so the custom install script will still be needed for a bit.
Yes, resolving extra meta info from the registry is a massive problem in the We are discussing some other solutions for native packages npm/rfcs#438 (comment) |
Co-authored-by: Steven <[email protected]>
break | ||
} catch (e) {} | ||
} | ||
|
||
if (!bindings) { |
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 need this block any more?
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 don't think we should for most cases although we could leave it in case users want to manually install the package and skip our custom install script 🤔
Stats from current PRDefault Build (Decrease detected ✓)General Overall increase
|
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
buildDuration | 18.5s | 18.8s | |
buildDurationCached | 4.1s | 4.2s | |
nodeModulesSize | 355 MB | 355 MB |
Page Load Tests Overall decrease ⚠️
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
/ failed reqs | 0 | 0 | ✓ |
/ total time (seconds) | 3.995 | 3.996 | 0 |
/ avg req/sec | 625.77 | 625.62 | |
/error-in-render failed reqs | 0 | 0 | ✓ |
/error-in-render total time (seconds) | 2.067 | 2.189 | |
/error-in-render avg req/sec | 1209.71 | 1141.99 |
Client Bundles (main, webpack, commons)
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
450.HASH.js gzip | 179 B | 179 B | ✓ |
framework-HASH.js gzip | 42.2 kB | 42.2 kB | ✓ |
main-HASH.js gzip | 27.2 kB | 27.2 kB | ✓ |
webpack-HASH.js gzip | 1.44 kB | 1.44 kB | ✓ |
Overall change | 71 kB | 71 kB | ✓ |
Legacy Client Bundles (polyfills)
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
polyfills-HASH.js gzip | 31 kB | 31 kB | ✓ |
Overall change | 31 kB | 31 kB | ✓ |
Client Pages
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
_app-HASH.js gzip | 1.37 kB | 1.37 kB | ✓ |
_error-HASH.js gzip | 194 B | 194 B | ✓ |
amp-HASH.js gzip | 312 B | 312 B | ✓ |
css-HASH.js gzip | 326 B | 326 B | ✓ |
dynamic-HASH.js gzip | 2.37 kB | 2.37 kB | ✓ |
head-HASH.js gzip | 350 B | 350 B | ✓ |
hooks-HASH.js gzip | 919 B | 919 B | ✓ |
image-HASH.js gzip | 4.87 kB | 4.87 kB | ✓ |
index-HASH.js gzip | 263 B | 263 B | ✓ |
link-HASH.js gzip | 2.13 kB | 2.13 kB | ✓ |
routerDirect..HASH.js gzip | 321 B | 321 B | ✓ |
script-HASH.js gzip | 383 B | 383 B | ✓ |
withRouter-HASH.js gzip | 318 B | 318 B | ✓ |
85e02e95b279..7e3.css gzip | 107 B | 107 B | ✓ |
Overall change | 14.2 kB | 14.2 kB | ✓ |
Client Build Manifests
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
_buildManifest.js gzip | 459 B | 459 B | ✓ |
Overall change | 459 B | 459 B | ✓ |
Rendered Page Sizes
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
index.html gzip | 531 B | 531 B | ✓ |
link.html gzip | 545 B | 545 B | ✓ |
withRouter.html gzip | 526 B | 526 B | ✓ |
Overall change | 1.6 kB | 1.6 kB | ✓ |
Default Build with SWC (Increase detected ⚠️ )
General Overall increase ⚠️
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
buildDuration | 23.3s | 23.5s | |
buildDurationCached | 4.2s | 4.1s | -34ms |
nodeModulesSize | 355 MB | 355 MB |
Page Load Tests Overall increase ✓
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
/ failed reqs | 0 | 0 | ✓ |
/ total time (seconds) | 4 | 4.061 | |
/ avg req/sec | 624.94 | 615.55 | |
/error-in-render failed reqs | 0 | 0 | ✓ |
/error-in-render total time (seconds) | 2.159 | 2.117 | -0.04 |
/error-in-render avg req/sec | 1157.86 | 1180.64 | +22.78 |
Client Bundles (main, webpack, commons)
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
450.HASH.js gzip | 179 B | 179 B | ✓ |
framework-HASH.js gzip | 42.3 kB | 42.3 kB | ✓ |
main-HASH.js gzip | 27.3 kB | 27.3 kB | ✓ |
webpack-HASH.js gzip | 1.44 kB | 1.44 kB | ✓ |
Overall change | 71.3 kB | 71.3 kB | ✓ |
Legacy Client Bundles (polyfills)
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
polyfills-HASH.js gzip | 31 kB | 31 kB | ✓ |
Overall change | 31 kB | 31 kB | ✓ |
Client Pages
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
_app-HASH.js gzip | 1.35 kB | 1.35 kB | ✓ |
_error-HASH.js gzip | 180 B | 180 B | ✓ |
amp-HASH.js gzip | 305 B | 305 B | ✓ |
css-HASH.js gzip | 321 B | 321 B | ✓ |
dynamic-HASH.js gzip | 2.36 kB | 2.36 kB | ✓ |
head-HASH.js gzip | 342 B | 342 B | ✓ |
hooks-HASH.js gzip | 911 B | 911 B | ✓ |
image-HASH.js gzip | 4.88 kB | 4.88 kB | ✓ |
index-HASH.js gzip | 256 B | 256 B | ✓ |
link-HASH.js gzip | 2.19 kB | 2.19 kB | ✓ |
routerDirect..HASH.js gzip | 314 B | 314 B | ✓ |
script-HASH.js gzip | 375 B | 375 B | ✓ |
withRouter-HASH.js gzip | 309 B | 309 B | ✓ |
85e02e95b279..7e3.css gzip | 107 B | 107 B | ✓ |
Overall change | 14.2 kB | 14.2 kB | ✓ |
Client Build Manifests
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
_buildManifest.js gzip | 459 B | 459 B | ✓ |
Overall change | 459 B | 459 B | ✓ |
Rendered Page Sizes
vercel/next.js canary | ijjk/next.js update/swc-downloading | Change | |
---|---|---|---|
index.html gzip | 532 B | 532 B | ✓ |
link.html gzip | 545 B | 545 B | ✓ |
withRouter.html gzip | 526 B | 526 B | ✓ |
Overall change | 1.6 kB | 1.6 kB | ✓ |
// should we fallback to wasm in this case? | ||
console.error( | ||
`Error: unsupported next-swc platform: ` + | ||
`${process.platform} ${process.arch} (glibc: ${isGlibc})\n` + |
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.
`${process.platform} ${process.arch} (glibc: ${isGlibc})\n` + | |
`${process.platform} ${process.arch} (glibcVersionRuntime: ${glibcVersionRuntime})\n` + |
Follow-up to #36527 this adds falling back to the wasm swc build when loading the native bindings fails so that we don't block the build on the native dependency being available. This continues off of #33496 but does not add a postinstall script yet and only downloads the fallback when the native dependency fails to load.
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.
Going to close this for now as we have wasm fallback handling now and taking separate steps to refine this installation process.
This continues the work in #32850 to reduce install size/time for the
next-swc
binary. SinceoptionalDependencies
don't allow us to accurately download the specific binary we need per-platform since platforms can matcharch
andplatform
but still need a different binary e.g.musl
vsglibc
for linux this adds a custom install script which will directly download the correct binary.Initial testing seems to reduce install time by 2 -3 seconds on mac OS and Windows even without the local cache for the
next-swc
binary being leveraged. We can expand on the install script in the future to download the WASM variant ofnext-swc
if a platform specific binary is not available yet.before (yarn cache was cleared before run)
after (yarn cache was cleared before run)