Questions about webpack’s design philosophy: chunking, `manifest.json`, and exposing symbols for external use

Viewed 40

I’m fairly new to webpack and trying to understand its design philosophy to better guide our firm’s migration to it. In particular, I’m using Ruby on Rails’ webpacker gem, which works like a charm; however, I still am uncertain about certain aspects of webpack's internals:

  1. In this calculation, multiple entry points can be retrieved by concatenating their chunks (in order) and removing chunks that appear multiple times. Is this a common calculation across the webpack ecosystem? If so, is there a link to the webpack documentation that describes a similar calculation? The above behavior would also suggest the webpack analyzes all entry points as a whole and chunks based on that. Does it also maintain the property that all chunk groups are disjoint in terms of code? If not, then the webpacker code snippet isn’t correct.
  2. Is it a convention to consult manifest.json and identify the chunks associated with an entry point? In webpacker, it’s a helper to generate the script tags, and am I understanding correctly that the general-purpose version of this is html-webpack-plugin? I get the concept of dynamic imports (import(“foo”); instead of import “foo”;), but aside from this and manifest.json, is there another way to discover names of chunks that an entry point depends on?
  3. If webpack’s purpose is to build self-contained artifacts like React apps, does that mean it’s less good at exporting symbols to the outside JS environment? In particular, I'm thinking of the use case of inline JavaScripts which use global symbols. The expose-loader seems to fulfill this role, but I wonder if there’s a more structured way of doing so, like (speculating here) optionally providing a global Webpack object with a CommonJS-like module.exports syntax containing symbols that the user chooses to expose.

Thanks in advance for any insights into these long-winded questions!

0 Answers
Related