feat(pack): LibraryChunkingContext use EdgeWorker to avoid async chunk split

[fireairforce]

Summary

EdgeWorker 的 chunking context 可以决定: https://github.com/utooland/next.js/blob/utoo/turbopack/crates/turbopack-core/src/chunk/chunk_group.rs#L54

更大程度避免在 library 打包的时候出现异步 chunk 拆分:

Test Plan

[gemini-code-assist]

Summary of Changes

Hello @fireairforce, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances Turbopack's library bundling capabilities by enforcing the use of an EdgeWorker environment within the LibraryChunkingContext. This strategic change is designed to prevent asynchronous chunk splitting, ensuring that libraries, even those containing dynamic imports, are consolidated into a single output chunk. This behavior is crucial for optimizing library distribution and consumption. The changes are validated through a new dedicated snapshot test case, alongside a general reorganization of related test files to improve maintainability.

Highlights

• Library Chunking Context: The LibraryChunkingContext has been updated to explicitly use an EdgeWorker environment, overriding any provided environment.
• Async Chunk Splitting Prevention: This change prevents asynchronous chunk splitting when bundling libraries, ensuring that even dynamic imports within a library are included in a single chunk.
• New Test Case for Library Bundling: A new snapshot test case has been added to verify the correct behavior of library chunking with dynamic imports, confirming that no separate chunks are generated.
• Test Suite Reorganization: Existing dynamic import and external snapshot tests have been reorganized and renamed for better clarity and structure within the test suite.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request cleverly utilizes the EdgeWorker environment within the LibraryChunkingContext to prevent async chunk splitting during library builds. This ensures that libraries with dynamic imports are bundled as single, self-contained files. The implementation is straightforward and is accompanied by a new test case that validates the behavior. The refactoring of other snapshot tests, while making the diff larger, appears correct. I have one suggestion to improve a code comment for better long-term maintainability.

[xusd320]

这样的话 dynamic_import_to_require 还需要吗？

[fireairforce]

好像也可以去掉了，这里会自动处理成 inline 的 import，我更新一下

[fireairforce]

跟 app 一样默认关闭了，看上去不会拆出额外的 chunk 来

[xusd320]

Ref: #2461