Node.js production runtime POC #4998
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
9 Ignored Deployments
|
|
✅ This change can build |
| @@ -0,0 +1,359 @@ | |||
| /* eslint-disable @next/next/no-assign-module-variable */ | |||
There was a problem hiding this comment.
This is a slimmed down version of our dev runtime that doesn't include HMR.
It's currently missing some more recent updates to our dev runtime.
Eventually, this runtime should be optimized for conciseness and performance. But for now, readability is privileged.
crates/turbopack-build/src/ecmascript/node/manifest/chunk_asset.rs
Outdated
Show resolved
Hide resolved
|
This comment was marked as resolved.
This comment was marked as resolved.
|
The Socket comment has nothing to do with this PR, and relates to test fixtures. cc @mehulkar might need to update these fixtures? |
alexkirsz
force-pushed
the
alexkirsz/web-397-next-build-poc
branch
from
76f4386
to
0189585
Compare
|
@alexkirsz oh i see you're talking about socket, my bad. Yeah you can ignore this. |
There was a problem hiding this comment.
I quite dislike the duplication of the runtime code. Could we move the shared part to turbopack-ecmascript? (I want to avoid dev to prod differences as this could lead to production only problems)
We originally had the the logic for import() in turbopack-dev as it uses an extra indirection (manifest chunk) to allow lazy compiling the graph behind the import(). This won't be needed in prod. But I think it's ok to have it in turbopack-ecmascript and maybe use some kind of ChunkingContext trait method to control if the manifest module should be in a separate chunk or not.
alexkirsz
force-pushed
the
alexkirsz/web-397-next-build-poc
branch
from
0189585
to
8e19721
Compare
|
Turning this back into a draft while I address #4998 (comment) |
alexkirsz
force-pushed
the
alexkirsz/web-397-next-build-poc
branch
from
92031a1
to
0af9e35
Compare
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
alexkirsz
force-pushed
the
alexkirsz/web-397-next-build-poc
branch
from
b106450
to
9b463a5
Compare
This PR is extracted from #49942 and mostly contains changes necessary after the Turbopack PR adding the Node.js production runtime vercel/turbo#4998, without any of the actual Next Build stuff, in order to be able to merge both quickly. * ChunkData moved from tp-dev to tp-core, the ES-serializable part moved to tp-ecmascript; * all runtime types moved to tp-ecmascript-runtime This also upgrades Turbopack to turbopack-230526.2: * vercel/turbo#5102 <!-- Donny/강동윤 - refactor: Fix binary bloat caused by `ValueDebugFormat` impl --> * vercel/turbo#4998 <!-- Alex Kirszenberg - Node.js production runtime POC -->
…el#50375) This PR is extracted from vercel#49942 and mostly contains changes necessary after the Turbopack PR adding the Node.js production runtime vercel/turbo#4998, without any of the actual Next Build stuff, in order to be able to merge both quickly. * ChunkData moved from tp-dev to tp-core, the ES-serializable part moved to tp-ecmascript; * all runtime types moved to tp-ecmascript-runtime This also upgrades Turbopack to turbopack-230526.2: * vercel/turbo#5102 <!-- Donny/강동윤 - refactor: Fix binary bloat caused by `ValueDebugFormat` impl --> * vercel/turbo#4998 <!-- Alex Kirszenberg - Node.js production runtime POC -->
This contains the original POC for `next build --turbo`. The implementation is _just enough_ to get pages building, and doesn't support the app router yet. I'll write more details here on the implementation and what the next steps are next week. Necessary changes on the Turbo side: vercel/turbo#4998
Description
This implements a Node.js production runtime for Turbopack, to first be used for
next build --turbo, but that can easily be extended to support more production use cases (e.g. ncc).The runtime works differently from the dev runtime we're currently using for
next dev: instead of having each chunk register itself against a global registry when evaluated, chunks export their module factories as a CommonJS default export. The runtime itself lives in a separate chunk, and then an "exported chunk" is generated that instantiates runtime entries and exports a given entry module.Corresponding Next.js PR:
vercel/next.js#49942vercel/next.js#50375