-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Chunking Refactor pt. 2 #4450
Chunking Refactor pt. 2 #4450
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
6 Ignored Deployments
|
75b76ba
to
197daa9
Compare
🟢 CI successful 🟢Thanks |
197daa9
to
c680de9
Compare
✅ This changes can build |
624bba3
to
1718e24
Compare
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.
Let's wait until after the next.js release before merging that
pub fn new(chunks: AssetsVc) -> Self { | ||
Self::cell(ChunkGroupReference { chunks }) | ||
} | ||
} | ||
|
||
#[turbo_tasks::value_impl] | ||
impl AssetReference for ChunkGroupReference { | ||
#[turbo_tasks::function] | ||
async fn resolve_reference(&self) -> Result<ResolveResultVc> { | ||
let set = self.chunk_group.chunks().await?.clone_value(); | ||
let set = self.chunks.await?.clone_value(); |
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.
This is eager instead of lazy now...
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.
If I'm not mistaken, this specific line was always eager. However, creating a chunk group reference was not.
4fb5f34
to
fadfc43
Compare
fadfc43
to
84d3130
Compare
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.
Great to see all these __turbopack_register_chunk_list__()
calls to be gone
if let Some(ecmascript_chunk) = EcmascriptChunkVc::resolve_from(chunk).await? { | ||
EcmascriptDevChunkVc::new(self_vc, ecmascript_chunk).into() | ||
} else { | ||
chunk.into() |
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.
This only works when trait Chunk : Asset
. Don't you want to remove this?
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.
Yes, this will eventually have to go. But for now, in order to keep supporting CSS chunks without modifications, we have to do this.
assets.push(self_vc.generate_chunk_list_register_chunk( | ||
entry_chunk, | ||
AssetsVc::cell(assets.clone()), | ||
Value::new(EcmascriptDevChunkListSource::Dynamic), | ||
)); |
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.
This looks like a race condition. chunk list is registered maybe before or maybe after the chunk are loaded. It should probably register it before the chunks are loaded and also wait for ack
from the dev server. But this is already broken, so we can ignore that for now... We can solve that together with solving the initial registration
Ok(parent | ||
.references() | ||
.await? | ||
.iter() | ||
.copied() | ||
.map(reference_to_chunks) | ||
.try_join() | ||
.await? | ||
.into_iter() | ||
.flatten()) |
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.
The Chunk
trait should have a parallel_chunks()
method to expose parallel chunks. references()
should no longer contain parallel chunks
children: Vec<ChunksVc>, | ||
_chunk_group: ChunkGroupVc, | ||
) -> Result<ChunksVc> { | ||
async fn optimize_ecmascript(local: Option<ChunksVc>, children: Vec<ChunksVc>) -> Result<ChunksVc> { |
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.
This function might move into turbopack-dev
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.
At this point, the whole optimize module should move into turbopack-dev.
The remaining comments will be addressed in pt. 3. |
See vercel/turborepo#4450 This PR updates Turbopack to turbopack-230411.2: ## Miscellaneous * vercel/turborepo#4450 <!-- Alex Kirszenberg - Chunking Refactor pt. 2 -->
See vercel/turborepo#4450 This PR updates Turbopack to turbopack-230411.2: ## Miscellaneous * vercel/turborepo#4450 <!-- Alex Kirszenberg - Chunking Refactor pt. 2 -->
### Description This PR does two things, addressing related comments from #4450: 1. Replace `ChunkReferenceVc` and `ParallelChunkReferenceVc` with `Chunk::parallel_chunks`. 2. Moves all non-generic optimization logic out of `turbopack-core` and into `turbopack-dev`. These optimization methods are very specific to a development environment, and `turbopack-build` will have different ones. ### Testing Instructions Snapshots link WEB-891
…el#4546) ### Description This PR does two things, addressing related comments from vercel#4450: 1. Replace `ChunkReferenceVc` and `ParallelChunkReferenceVc` with `Chunk::parallel_chunks`. 2. Moves all non-generic optimization logic out of `turbopack-core` and into `turbopack-dev`. These optimization methods are very specific to a development environment, and `turbopack-build` will have different ones. ### Testing Instructions Snapshots link WEB-891
### Description Next.js side: #47961 Previous episode: vercel/turborepo#4397 In this episode, we: 1. Get rid of `ChunkGroupVc`. `ChunkGroupVc` previously took care of: a. optimizing chunks; b. adding additional chunks, such as the "evaluate" chunk, which evaluates runtime entries. Both of these use cases are a concern of the chunking context (i.e. it would differ between dev and build), hence they're now handled by the chunking context. 2. Move the chunk list registration logic into a different chunk. The chunk list was previously a bit leaky as it required the Next.js code to instantiate it manually. There were also a bunch of other instantiations in the code which differed ever so slightly. The chunk list registration code is now part of a separate chunk, which is only added by the dev chunking context. ### Testing Instructions Snapshots + Next dev tests + Manual tests fix WEB-822
…el/turborepo#4546) ### Description This PR does two things, addressing related comments from vercel/turborepo#4450: 1. Replace `ChunkReferenceVc` and `ParallelChunkReferenceVc` with `Chunk::parallel_chunks`. 2. Moves all non-generic optimization logic out of `turbopack-core` and into `turbopack-dev`. These optimization methods are very specific to a development environment, and `turbopack-build` will have different ones. ### Testing Instructions Snapshots link WEB-891
### Description Next.js side: #47961 Previous episode: vercel/turborepo#4397 In this episode, we: 1. Get rid of `ChunkGroupVc`. `ChunkGroupVc` previously took care of: a. optimizing chunks; b. adding additional chunks, such as the "evaluate" chunk, which evaluates runtime entries. Both of these use cases are a concern of the chunking context (i.e. it would differ between dev and build), hence they're now handled by the chunking context. 2. Move the chunk list registration logic into a different chunk. The chunk list was previously a bit leaky as it required the Next.js code to instantiate it manually. There were also a bunch of other instantiations in the code which differed ever so slightly. The chunk list registration code is now part of a separate chunk, which is only added by the dev chunking context. ### Testing Instructions Snapshots + Next dev tests + Manual tests fix WEB-822
…el/turborepo#4546) ### Description This PR does two things, addressing related comments from vercel/turborepo#4450: 1. Replace `ChunkReferenceVc` and `ParallelChunkReferenceVc` with `Chunk::parallel_chunks`. 2. Moves all non-generic optimization logic out of `turbopack-core` and into `turbopack-dev`. These optimization methods are very specific to a development environment, and `turbopack-build` will have different ones. ### Testing Instructions Snapshots link WEB-891
### Description Next.js side: #47961 Previous episode: vercel/turborepo#4397 In this episode, we: 1. Get rid of `ChunkGroupVc`. `ChunkGroupVc` previously took care of: a. optimizing chunks; b. adding additional chunks, such as the "evaluate" chunk, which evaluates runtime entries. Both of these use cases are a concern of the chunking context (i.e. it would differ between dev and build), hence they're now handled by the chunking context. 2. Move the chunk list registration logic into a different chunk. The chunk list was previously a bit leaky as it required the Next.js code to instantiate it manually. There were also a bunch of other instantiations in the code which differed ever so slightly. The chunk list registration code is now part of a separate chunk, which is only added by the dev chunking context. ### Testing Instructions Snapshots + Next dev tests + Manual tests fix WEB-822
…el/turborepo#4546) ### Description This PR does two things, addressing related comments from vercel/turborepo#4450: 1. Replace `ChunkReferenceVc` and `ParallelChunkReferenceVc` with `Chunk::parallel_chunks`. 2. Moves all non-generic optimization logic out of `turbopack-core` and into `turbopack-dev`. These optimization methods are very specific to a development environment, and `turbopack-build` will have different ones. ### Testing Instructions Snapshots link WEB-891
Description
Next.js side: vercel/next.js#47961
Previous episode: #4397
In this episode, we:
ChunkGroupVc
.ChunkGroupVc
previously took care of:a. optimizing chunks;
b. adding additional chunks, such as the "evaluate" chunk, which evaluates runtime entries.
Both of these use cases are a concern of the chunking context (i.e. it would differ between dev and build), hence they're now handled by the chunking context.
Testing Instructions
Snapshots + Next dev tests + Manual tests
fix WEB-822