Node.js production runtime POC #4998
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
9 Ignored Deployments
|
|
✅ This change can build |
alexkirsz
commented
May 17, 2023
| @@ -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
commented
May 22, 2023
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. |
sokra
requested changes
May 23, 2023
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) |
sokra
reviewed
May 24, 2023
alexkirsz
force-pushed
the
alexkirsz/web-397-next-build-poc
branch
from
92031a1
to
0af9e35
Compare
Co-authored-by: Tobias Koppers <[email protected]>
alexkirsz
force-pushed
the
alexkirsz/web-397-next-build-poc
branch
from
b106450
to
9b463a5
Compare
sokra
approved these changes
May 26, 2023
sokra
pushed a commit
to vercel/next.js
that referenced
this pull request
May 26, 2023
This PR is extracted from #49942 and mostly contains changes necessary after the Turbopack PR adding the Node.js production runtime vercel/turborepo#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/turborepo#5102 <!-- Donny/강동윤 - refactor: Fix binary bloat caused by `ValueDebugFormat` impl --> * vercel/turborepo#4998 <!-- Alex Kirszenberg - Node.js production runtime POC -->
hydRAnger
pushed a commit
to hydRAnger/next.js
that referenced
this pull request
Jun 12, 2023
…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/turborepo#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/turborepo#5102 <!-- Donny/강동윤 - refactor: Fix binary bloat caused by `ValueDebugFormat` impl --> * vercel/turborepo#4998 <!-- Alex Kirszenberg - Node.js production runtime POC -->
kodiakhq bot
pushed a commit
to vercel/next.js
that referenced
this pull request
Jun 19, 2023
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/turborepo#4998
ForsakenHarmony
pushed a commit
to vercel/next.js
that referenced
this pull request
Jul 25, 2024
### 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: ~~#49942 #50375 --------- Co-authored-by: Tobias Koppers <[email protected]>
ForsakenHarmony
pushed a commit
to vercel/next.js
that referenced
this pull request
Jul 29, 2024
### 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: ~~#49942 #50375 --------- Co-authored-by: Tobias Koppers <[email protected]>
ForsakenHarmony
pushed a commit
to vercel/next.js
that referenced
this pull request
Aug 1, 2024
### 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: ~~#49942 #50375 --------- Co-authored-by: Tobias Koppers <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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