Rails 6中webpacker的理想pack数量是多少？兼顾构建耗时

Great question! There’s no one-size-fits-all "ideal" number of packs—it depends entirely on your project’s size, structure, and the tradeoffs you’re willing to make between build speed and code organization. Let’s break this down with practical context:

Key Tradeoffs to Tie to Your Experience #

First, let’s connect your observed build times (4 packs = 7s, 1 pack = 3s) to what’s happening under the hood:

• More packs mean Webpack has to process separate entry points, which adds overhead if there’s duplicated dependencies across packs (e.g., loading Bootstrap or React in multiple packs without proper splitting).
• Fewer packs cut down on build overhead but can lead to larger individual bundle sizes (though this is far less of an issue with HTTP/2, which handles multiple small files better than older HTTP versions).

Recommendations Based on Project Scale #

Small to Medium Projects (Most Common) #

Stick with 1-2 packs if:

• Most of your pages share core dependencies (e.g., a common UI framework, utility functions).
• You don’t have distinct, isolated sections (like an admin dashboard with entirely separate tools and dependencies).
• Your current 3-second build time is completely acceptable for both development and production workflows.

This is the simplest, most efficient approach—you’ll minimize build overhead while keeping your setup easy to maintain. For example:

• application.js for all frontend user-facing pages.
• admin.js only if your admin area uses drastically different libraries (e.g., a specialized charting tool or enterprise UI kit).

Large/Complex Projects #

If your app has distinct, independent sections (e.g., public site, admin dashboard, checkout flow, internal API client), 3-5 packs can be a sweet spot—but only if you optimize dependencies to avoid duplication. Here’s why this works:

• Splitting by feature lets you build only the pack you’re actively working on during development (if you configure Webpacker to watch specific entry points instead of all packs).
• It reduces unnecessary code for end users (e.g., a checkout visitor doesn’t load admin-specific assets).

To avoid the build time spike you saw with 4 packs, implement these optimizations:

• Extract shared third-party dependencies into a separate vendor.js pack. This way, Webpack only compiles these rarely changing dependencies once, not per pack.
• Enable Webpack’s built-in caching (cache: true in your Webpack config) to reuse compiled assets between builds.
• Use Webpacker’s webpack-dev-server with hot module replacement (HMR) to avoid full rebuilds when you make code changes.

Final Takeaway for Your Case #

If the 3-second build time with 1 pack works for your workflow and your app doesn’t need strict code isolation, keep it—this is the most efficient setup. If you do need to split (e.g., to separate admin and frontend code), start with 2 packs, optimize shared dependencies first, and monitor build times to ensure they don’t creep up too much.

The goal is to balance organization and speed—there’s no need to split packs just for the sake of following a "best practice."

内容的提问来源于stack exchange，提问作者Vivek Kumar