feat(pack): add target: node support for library builds#2683
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! 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 introduces comprehensive support for targeting Node.js environments when building libraries. It enables the build system to generate platform-specific output, ensuring that libraries intended for Node.js utilize a tailored runtime backend that avoids browser-specific APIs. This enhancement significantly expands the utility of library builds by allowing them to seamlessly integrate into Node.js applications while maintaining the benefits of single-file bundling. Highlights
Changelog
Activity
Using Gemini Code AssistThe 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
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 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds support for target: node in library builds, enabling platform-aware runtime backend selection. The changes are well-structured and include new test cases for the Node.js target. I've identified a few areas in crates/pack-api/src/library.rs where code duplication can be reduced to improve maintainability. My review includes specific suggestions for refactoring.
xusd320
force-pushed
the
feat/pack-library-node-target
branch
8 times, most recently
from
6477a94 to
18e1551
Compare
- Make library endpoint platform-aware: dispatch compile-time info, module options, and resolve options based on Platform (Web/Node) - Create Node.js-compatible runtime backend (runtime-backend-node.ts) without DOM APIs (no document.createElement, importScripts, etc.) - Conditionally select runtime backend in runtime_code.rs based on is_node_platform flag on LibraryChunkingContext - Always use EdgeWorker environment for library chunking context (ChunkLoading::Edge prevents async chunk splitting for single-file output) - Move and organize target_node snapshot tests under target_node/ - Add library_build_node_target test with dynamic import() to verify single-chunk enforcement and correct Node.js built-in externals
xusd320
force-pushed
the
feat/pack-library-node-target
branch
from
18e1551 to
915e4c1
Compare
📊 Performance Benchmark Report (with-antd)Utoopack Performance Report (Intelligent)Report ID: Executive SummaryKey Findings
Workload Distribution by Tier
🤖 AI Intelligent AttributionsNew section mapping granular tasks to bottlenecks. Top 10 Batching CandidatesThese highly-called tasks are dominated by a single parent. If the parent can batch them into one call, it drastically reduces scheduler overhead.
Top 20 Tasks by Total Duration
Duration Distribution
Action Items
Report generated by Intelligent Utoopack Performance Analysis Agent |
2 participants
Add target: node support for library builds with platform-aware runtime backend selection (DOM vs Node.js).