Concepts - Bundle vs Chunk

[zzzgit]

There is no definite definitions for the concepts bundle and chunk in the documentation of both V1 and V2.
After a learning for several days, I found that they guys use bundle and chunk in the documentation alternately. As if there isn't a clear difference between bundle and chunk.
Am I right?
If not, the effort for documentation improvement is needed.
If it is, I have two suggests:

1. use chunk instead of bundle everywhere, to avoid confusing
2. use chunk as a noun while bundle as a verb

[skipjack]

I have also grappled with this in the past and came to about the same conclusion. It might be tough to enforce one or the other now as there are so many instances of chunk and bundle across this site and elsewhere.

@TheLarkInn maybe a glossary section somewhere under Documentation would be useful at some point?

[rouzbeh84]

I think this is a good idea! I know it may sound easy to search for such terms but for those unfamiliar or new an easy index of all the keywords/domain specific words used around the web and this site itself could be useful to have if not just to link back to within posts on an automated path to hotlink the words during build process?

I went ahead and started one with a few words but didn't get too far just in case it's not wanted by many haha. here is a screen of the glossary branch I've begun. It links all words to their respective pages with more detail.

Thoughts?

[skipjack]

@rouzbeh84 I really like this idea and I think adding it under /content/glossary.md is perfect as it doesn't really fit it any particular section. Aside from linking to it throughout other pages, I'm not sure where the main link would be (e.g. banner, sidebar, footer). I think maybe the footer would be best but maybe we should remove/move some of those other links. Our content is definitely starting to overflow our layout 😭 but were working on that in #438 and #1153.

Feel free to PR whenever though, and close this issue (just make sure to include Bundle and Chunk definitions 😉 ).

[rouzbeh84]

@skipjack it could be hot-linked throughout the docs and possibly the last item on the left list for easy access while going throughout?

Would it be possible to do add some sort of grepping to the build process that generates all used words on the section and put them in a dropdown style link in the left nav like how most sections are populated now?

[skipjack]

it could be hot-linked throughout the docs and possibly the last item on the left list for easy access while going throughout?

Yeah, I was thinking about the bottom of the sidebar as well. That may be a good fit.

Would it be possible to do add some sort of grepping to the build process that generates all used words on the section and put them in a dropdown style link in the left nav like how most sections are populated now?

Anything's possible 😆 ... I'm a little confused as to what you mean by adding it to the sidebar. Maybe you can show me an example? I think what would be really cool is if we grep-ed them as you said and then highlighted them as key terms (maybe with a hover behavior showing the definition).

Let's keep it simple for now and revisit that second part (grep-ing / highlighting / extracting) down the road. I want to avoid adding any more major features/complexity to the site for the time being until we get the issue count down and have some time to clean things up. Here's the roadmap I have in my head...

Knock down remaining issue count (aka get content into a good place) =>
Review and clean up content (grammatical errors, simplification, etc.) =>
Clean up infrastructure/setup (markdown.js 😞 , build/testing setup, etc.) =>
Revisit some of the things we passed over earlier (like step 2 here) and add new features

Doesn't have to be exactly synchronous like that, in fact @bebraw and I are working on a few non-content-related things currently, but I think in general that should be the plan.

[rouzbeh84]

@skipjack

I'm a little confused as to what you mean by adding it to the sidebar. Maybe you can show me an example?

Sorry if I was unclear about the sidebar. I think we're on the same page as I basically meant adding the collected glossary values of current page to a nested list at the bottom like the other sections have. Possibly with a border above to denote it's a type of constant navigation feature? Probably not needed but this type of thing image of sidebar

I think what would be really cool is if we grep-ed them as you said and then highlighted them as key terms (maybe with a hover behavior showing the definition).

This would be really cool!

Let's keep it simple for now and revisit that second part (grep-ing / highlighting / extracting) down the road. I want to avoid adding any more major features/complexity to the site for the time being until we get the issue count down and have some time to clean things up. Here's the roadmap I have in my head...

For sure! I know I'm not too familiar with the build process of this site so just spitballing but will keep it simple for now to get something up and see if it's useful in the first place before altering any build steps.

[skipjack]

I know I'm not too familiar with the build process of this site so just spitballing but will keep it simple for now to get something up and see if it's useful in the first place before altering any build steps.

Yeah, no worries... I think it would fit in somewhere in the markdown processing but let's just get the page up and loop back to this down the road once the markdown.js file has been reworked into something else or cleaned up significantly. It's already been causing a fair amount of issues like #1187, #178 and probably a few others we don't yet know about.

Let's just start by getting that page up, and maybe linking to it from a few places. Ping me once you have something ready for review.

[dwiyatci]

Nice to find this thread! 😃

I have also grappled with this in the past and came to about the same conclusion.

@skipjack So they are actually the same, then? I've also been silently questioning this concept for the past 2 years and used to think that bundle is a collection of chunks ... 😅

[skipjack]

@skipjack So they are actually the same, then? I've also been silently questioning this concept for the past 2 years and used to think that bundle is a collection of chunks...

@dwiyatci Yes I believe they are the same. I had initially thought that "chunks" were analogous with child bundles (similar to your thought that "a bundle is a collection of chunks") but I've also heard the term "entry chunk" used which kind of voids that thought. I'm not an expert though, I would leave the final say to someone from the @webpack/core-team.

[rouzbeh84]

gonna watch this deep dive into code splitting: under the hood by @TheLarkInn and after understanding will add to glossary.

In the meantime, according to survivejs

• Bundle is the result of bundling. Bundling involves processing the source material of the application into a final bundle that is ready to use. A bundler can generate more than one bundle.
  ...
• Chunk is a webpack-specific term that is used internally to manage the bundling process. Webpack composes bundles out of chunks, and there are several types of those.

[skipjack]

@rouzbeh84 you should feel free to pr this page whenever. We can always do follow ups to add and clean up content, doesn't have to be perfect on the first pass.

[dwiyatci]

Ähmm.., sounds to me the @survivejs definition goes more to a direction of bundle ≈ asset 🙃

[bebraw]

A bundle can consist of multiple assets especially if you inline some.

[rouzbeh84]

started PR #1223 for this. definitely a help wanted one but should I create a new issue for it with help-wanteed label?

[skipjack]

@rouzbeh84 let's just leave the PR open for a bit to get feedback and possible additions. I think if we make sure it's visible people will inherently consider adding terms there... there may also be some other open issues that could be resolved using the new glossary.

I'm really trying to knock the issue count down bit by bit, so I'm hesitant to open anything new right now as I'd like to keep the focus as much on cleaning up what we have and filling in the missing bits. Once we have things a bit more under control, then yeah opening an issue to discuss more terms might make sense, if that hasn't already happened naturally.

I'm reviewing and sorting out some odd build/test errors on your pr now...

[rouzbeh84]

@skipjack yep makes sense on both counts! Any idea why the builds failed? I don't think I saw any errors when submitting it unless I didn't wait long enough. Could it be that the file is new and on the root of content folder?

[skipjack]

Could it be that the file is new and on the root of content folder?

Nope, the first was a JSON error during the fetch that I haven't seen before and the others were just random link errors not related to your new page. However, I did notice that the links on the new page aren't being tested yet as no where else links to it yet. We should figure that out before merging.

[rafaeleyng]

I've checked the glossary and the question "bundle vs chunk" still remains for me.

Example:

Say I have well-known configuration that results in 3 output files (app.js, vendor.js, app.css). Say also that app.js contains an inlined image using the appropriate loader. So in my distfolder only these 3 files exist (2 .js, 1 .css).

Questions:

• How many assets I have here?
• How many bundles?
• How many chunks?
• Is each file a bundle? If so, what is a chunk in this scenario, then?
• Or else, is each file a chunk? If so, what is a bundle in this scenario, then?

---

Both the definitions in the glossary don't mention the output files, that ultimately is our goal when building with Webpack, so I don't understand how both concepts map to the output files.

[skipjack]

@rafaeleyng very good questions... let's re-open and figure out a way to better answer those somewhere in the docs.

@bebraw I think I have a rough idea on some of these but I'm interested in what you would say as well...

How many assets I have here?

Just 1 -- the css file as it was extracted out of the main bundle. Even though it's still a bunch of css files concatenated I think it counts more as an asset in webpack's view than a bundle.

How many bundles?

2 -- both the app.js and vendor.js files would count as bundles.

How many chunks?

Likely just 2 entry chunks but I think the correct answer here is that this is actually unknown. Chunks can be joined together so I think app.js could consist of multiple chunks depending on your plugins and settings.

Is each file a bundle? If so, what is a chunk in this scenario, then?

I think this is answered above but basically the output js files are bundles. Chunks would be what you declared as your entry points and any children of those entry points. There is definitely some overlap there but I think the point is it's not always a direct mapping from chunk => bundle.

Or else, is each file a chunk? If so, what is a bundle in this scenario, then?

Answered above.

Again, not sure if these are all on the money, just my current understanding.

[rafaeleyng]

@skipjack Thanks a lot.

So, as I see:

• every .js file in the output is a bundle. So bundles are .js files in the output directory

• chunk, on the other hand, seems to be related to the code itself, not to files. So 1 bundle has 1..n chunks. But a chunk is only contained in one bundle, or is possible that a chunk spread across multiple bundles? If that is the case, it would make it even harder to reason about.

In my idea above of what a chunk is, is it possible to, looking only at the output code, identify the chunks inside the bundles? Is there some marking that separates one chunk from the other?

[TheLarkInn]

Yes a chunk is a object oriented encapsulation of modules inside of the dependency graph. Really bundle was a term adopted by the community. Really a chunk takes all or a subtree of your modules in the deep graph. This allows chunkTemplate to render the wrapper around the modules when it is created and emitted to output directory.

[rafaeleyng]

In this article by @sokra it says (highlights are mine):

An application using this technique no longer emits a single file which can be included in the HTML file. It emits multiple chunks which all need to be loaded.
In an application using this optimization multiple script-tags are used to load every chunk (in parallel)

So, we have "multiple chunks" (which I still don't know what are, at this moment, whether they are the files or just parts of the code inside the files).

But the second highlight is even more confusing, because it says that every chunk will be loaded by multiple script-tags, so I understand from this that the same chunk might be splitted across several files (1 chunk in N files). With that, I give up trying to understand the relationship between chunks/bundles/files.

To sum up, I suggest coming up with good, unequivocal definitions for these terms, and keep in mind that whoever reads the glossary knows very little about webpack internals, so is important not to assume previous knowledge or use terms that need themselves further definitions.

[skipjack]

In an application using this optimization multiple script-tags are used to load every chunk (in parallel)

I'm pretty sure he means a script tag is needed to load each of the multiple chunks he mentioned in the previous statement. I agree the wording is not perfect. I think your initial thought...

So 1 bundle has 1..n chunks.

is correct. And the answer to:

is possible that a chunk spread across multiple bundles?

is no. @TheLarkInn @sokra can you clarify?

I suggest coming up with good, unequivocal definitions for these terms, and keep in mind that whoever reads the glossary knows very little about webpack internals, so is important not to assume previous knowledge or use terms that need themselves further definitions.

Sure, let's see what the rest of the team says and then we can update the glossary definitions and potentially some concept pages to reflect this discussion.

[bebraw]

A couple of quick points:

• I consider webpack output files (JavaScript) as bundles (that's what a bundler emits).
• Bundles contain chunks.
• Same chunks may be included in multiple bundles. Example: CommonsChunkPlugin default behavior. This is why it has those async and children flags so you can decide what to do with the common chunks across multiple bundles (whether to leave them to separated bundles or to push them to parent that loads them sync/async).
• Depending on the chunk type, it may or may not contain webpack runtime. At least the old configuration used three specific terms for the types (entry chunk, normal chunk (no runtime, see code splits (import()) and their output), initial chunks (something CommonsChunkPlugin related, you can see it in its source)).

Maybe the problem with the concept of chunk is that the term comes from webpack internals and the way it works. So unless you know what CommonsChunkPlugin is or why it's needed, it can be tricky to understand.

[TheLarkInn]

I'll try to paint this as clear as possible in the simplest explanation:

A chunk is a bundle.

Yes a chunk is a bundle. Chunk the class is the encapsulation for parts of your dependency graph.

There are three classifications of Chunks:

• Entry chunk - an entry chunk is an emitted file which contains the webpack runtime code. An example of that runtime code looks like this.

/******/ (function(modules) { // webpackBootstrap
/******/ 	// install a JSONP callback for chunk loading
/******/ 	var parentJsonpFunction = window["webpackJsonp"];
/******/ 	window["webpackJsonp"] = function webpackJsonpCallback(chunkIds, moreModules, executeModules) {
/******/ 		// add "moreModules" to the modules object,
/******/ 		// then flag all "chunkIds" as loaded and fire callback
/******/ 		var moduleId, chunkId, i = 0, resolves = [], result;
/******/ 		for(;i < chunkIds.length; i++) {
/******/ 			chunkId = chunkIds[i];
/******/ 			if(installedChunks[chunkId]) {
/******/ 				resolves.push(installedChunks[chunkId][0]);
/******/ 			}
/******/ 			installedChunks[chunkId] = 0;
/******/ 		}
/******/ 		for(moduleId in moreModules) {
/******/ 			if(Object.prototype.hasOwnProperty.call(moreModules, moduleId)) {
/******/ 				modules[moduleId] = moreModules[moduleId];
/******/ 			}
/******/ 		}
/******/ 		if(parentJsonpFunction) parentJsonpFunction(chunkIds, moreModules, executeModules);
/******/ 		while(resolves.length) {
/******/ 			resolves.shift()();
/******/ 		}
/******/
/******/ 	};
/******/
/******/ 	// The module cache
/******/ 	var installedModules = {};
/******/
/******/ 	// objects to store loaded and loading chunks
/******/ 	var installedChunks = {
/******/ 		7: 0
/******/ 	};
/******/
/******/ 	var resolvedPromise = new Promise(function(resolve) { resolve(); });
/******/
/******/ 	// The require function
/******/ 	function __webpack_require__(moduleId) {
/******/
/******/ 		// Check if module is in cache
/******/ 		if(installedModules[moduleId]) {
/******/ 			return installedModules[moduleId].exports;
/******/ 		}
/******/ 		// Create a new module (and put it into the cache)
/******/ 		var module = installedModules[moduleId] = {
/******/ 			i: moduleId,
/******/ 			l: false,
/******/ 			exports: {}
/******/ 		};
/******/
/******/ 		// Execute the module function
/******/ 		modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
/******/
/******/ 		// Flag the module as loaded
/******/ 		module.l = true;
/******/
/******/ 		// Return the exports of the module
/******/ 		return module.exports;
/******/ 	}
/******/
/******/ 	// This file contains only the entry chunk.
/******/ 	// The chunk loading function for additional chunks
/******/ 	__webpack_require__.e = function requireEnsure(chunkId) {
/******/ 		if(installedChunks[chunkId] === 0) {
/******/ 			return resolvedPromise;
/******/ 		}
/******/
/******/ 		// a Promise means "currently loading".
/******/ 		if(installedChunks[chunkId]) {
/******/ 			return installedChunks[chunkId][2];
/******/ 		}
/******/
/******/ 		// setup Promise in chunk cache
/******/ 		var promise = new Promise(function(resolve, reject) {
/******/ 			installedChunks[chunkId] = [resolve, reject];
/******/ 		});
/******/ 		installedChunks[chunkId][2] = promise;
/******/
/******/ 		// start chunk loading
/******/ 		var head = document.getElementsByTagName('head')[0];
/******/ 		var script = document.createElement('script');
/******/ 		script.type = 'text/javascript';
/******/ 		script.charset = 'utf-8';
/******/ 		script.async = true;
/******/ 		script.timeout = 120000;
/******/
/******/ 		if (__webpack_require__.nc) {
/******/ 			script.setAttribute("nonce", __webpack_require__.nc);
/******/ 		}
/******/ 		script.src = __webpack_require__.p + "" + chunkId + ".output.js";
/******/ 		var timeout = setTimeout(onScriptComplete, 120000);
/******/ 		script.onerror = script.onload = onScriptComplete;
/******/ 		function onScriptComplete() {
/******/ 			// avoid mem leaks in IE.
/******/ 			script.onerror = script.onload = null;
/******/ 			clearTimeout(timeout);
/******/ 			var chunk = installedChunks[chunkId];
/******/ 			if(chunk !== 0) {
/******/ 				if(chunk) {
/******/ 					chunk[1](new Error('Loading chunk ' + chunkId + ' failed.'));
/******/ 				}
/******/ 				installedChunks[chunkId] = undefined;
/******/ 			}
/******/ 		};
/******/ 		head.appendChild(script);
/******/
/******/ 		return promise;
/******/ 	};
/******/
/******/ 	// expose the modules object (__webpack_modules__)
/******/ 	__webpack_require__.m = modules;
/******/
/******/ 	// expose the module cache
/******/ 	__webpack_require__.c = installedModules;
/******/
/******/ 	// identity function for calling harmony imports with the correct context
/******/ 	__webpack_require__.i = function(value) { return value; };
/******/
/******/ 	// define getter function for harmony exports
/******/ 	__webpack_require__.d = function(exports, name, getter) {
/******/ 		if(!__webpack_require__.o(exports, name)) {
/******/ 			Object.defineProperty(exports, name, {
/******/ 				configurable: false,
/******/ 				enumerable: true,
/******/ 				get: getter
/******/ 			});
/******/ 		}
/******/ 	};
/******/
/******/ 	// getDefaultExport function for compatibility with non-harmony modules
/******/ 	__webpack_require__.n = function(module) {
/******/ 		var getter = module && module.__esModule ?
/******/ 			function getDefault() { return module['default']; } :
/******/ 			function getModuleExports() { return module; };
/******/ 		__webpack_require__.d(getter, 'a', getter);
/******/ 		return getter;
/******/ 	};
/******/
/******/ 	// Object.prototype.hasOwnProperty.call
/******/ 	__webpack_require__.o = function(object, property) { return Object.prototype.hasOwnProperty.call(object, property); };
/******/
/******/ 	// __webpack_public_path__
/******/ 	__webpack_require__.p = "js/";
/******/
/******/ 	// on error function for async loading
/******/ 	__webpack_require__.oe = function(err) { console.error(err); throw err; };
/******/
/******/ 	// Load entry module and return exports
/******/ 	return __webpack_require__(__webpack_require__.s = 5);
/******/ })
/************************************************************************/
// ^^ THIS IS THE RUNTIME CODE AND IT TAKES AN ARGUMENT WHICH IS AN ARRAY OF MODULES ^^
/******/ ({

/***/ 5:
/* unknown exports provided */
/* all exports used */
/*!********************!*\
  !*** ./example.js ***!
  \********************/
/***/ (function(module, exports, __webpack_require__) {

Promise.all/* require */([__webpack_require__.e(1), __webpack_require__.e(0), __webpack_require__.e(4)]).then(function() { var __WEBPACK_AMD_REQUIRE_ARRAY__ = [__webpack_require__(/*! ./a */ 0), __webpack_require__(/*! ./b */ 1), __webpack_require__(/*! ./c */ 2)]; (function(a, b, c) {}.apply(null, __WEBPACK_AMD_REQUIRE_ARRAY__));}).catch(__webpack_require__.oe);

Promise.all/* require.ensure */([__webpack_require__.e(1), __webpack_require__.e(0), __webpack_require__.e(3)]).then((function(require) {
	__webpack_require__(/*! ./b */ 1);
	__webpack_require__(/*! ./d */ 3);
}).bind(null, __webpack_require__)).catch(__webpack_require__.oe);

Promise.all/* require.ensure */([__webpack_require__.e(1), __webpack_require__.e(2)]).then((function(require) {
	__webpack_require__(/*! ./a */ 0);
	Promise.all/* require.ensure */([__webpack_require__.e(0), __webpack_require__.e(6)]).then((function(require) {
		__webpack_require__(/*! ./f */ 6);
	}).bind(null, __webpack_require__)).catch(__webpack_require__.oe);
	Promise.all/* require.ensure */([__webpack_require__.e(0), __webpack_require__.e(5)]).then((function(require) {
		__webpack_require__(/*! ./g */ 7);
	}).bind(null, __webpack_require__)).catch(__webpack_require__.oe);
}).bind(null, __webpack_require__)).catch(__webpack_require__.oe);


/***/ })

/******/ });

To be classified as an entry chunk, the emitted JS bundle/file must contain that bootstrap code seen above. Sometimes there will be no modules and they can be isolated into separate files. The entry chunk must always be executed first.

• Initial chunk: An initial chunk is loaded synchronously however doesn't contain the runtime code. If the modules seen in the example above were separated into their own file. The said file that would be created would be known as an initial chunk. Here is a similar example below where the modules are isolated to a separate initial chunk. The emitted file is a chunk, (in user land people just call it a bundle). Loading an initial chunk must always happen after its entry chunk is loaded first. This loads synchronously after the entry chunk has parsed and evaluated in the browser.

webpackJsonp([0],[
/* 0 */
/* unknown exports provided */
/* all exports used */
/*!*********************!*\
  !*** ./utility2.js ***!
  \*********************/
/***/ (function(module, exports) {

module.exports = "utility2";

/***/ }),
/* 1 */
/* unknown exports provided */
/* all exports used */
/*!*********************!*\
  !*** ./utility3.js ***!
  \*********************/
/***/ (function(module, exports) {

module.exports = "utility3";

/***/ })
]);

• Normal chunk - The only thing that separates an initial chunk from a normal chunk is how the file is loaded. Normal chunks are always lazy loaded and asynchronous. For example when I use require.ensure, or System.import or import(), webpack will separate any of the modules into a separate normal chunk.

All in all, a chunk is the abstraction in the source code that encapsulates and defines how groups of modules will be written to file.

Is it always one chunk for output file?

The only case where it is not, is when there are for example sourcemaps that are emitted alongside. These multiple assets that are written to disk are known as chunk assets.

[rafaeleyng]

Thanks for the discussion guys, it did help to clarify the topic.

[skipjack]

@rafaeleyng so based on the discussion do you think the glossary descriptions (or any other piece of the docs) should be updated? If so, any ideas on how to alter those descriptions to clarify things? We'd definitely welcome a PR if you're interested in submitting one.

[rafaeleyng]

@skipjack I would like to submit the PR, but to be honest, I still don't fully understand the difference. I just didn't want to push the discussion further. Didn't want to be too picky, you know. I think the only way for me to understand to the level that I would like is to study deeply the code, but I don't see that happening anytime soon.

[skipjack]

@rafaeleyng yea I totally understand, I think the discussion did help a bit but we definitely didn't reach a super-concise answer to this question. I'll discuss with the team a bit more and maybe take a stab at improving the definitions myself.

[harperj1029]

I appreciate the discussion but there are literally conflicting responses in here - even from some of the webpack people themselves. TheLarkInn says a chunk is a bundle, while bebrawb says bundles contain chunks. Also, this post [https://github.com//issues/970#issuecomment-305216411 ] from TheLarkInn unfortunately confuses me further by bringing up new terminology and raises even more questions in my mind.

I think it's easy for the people deep in webpack to lose sight of how confusing these "internal" terms are to people who just want to use the tool and don't live/breath/dream bundling.

[kimballjohnson]

I too, agree not to understand, in case my understanding should somehow become 'an understanding'... or fail to become one.

The fact that plugin writer's toss these terms about as well, but do so with more apparent assurance that this chain, indicates to me that chunk and bundle have an input/output relationship. But 'asset' merely 'is an instance', as in 'object is an instance'. However, an asset can appear to 'become' a chunk or a bundle if 'inlined', though it seems that an asset would be a trivial instance of one or the other.

But yes... it's clear that 'bundle' has to exist as an output of a 'bundler' since it engages in 'bundling'. And webpack's existence makes bundling a first-class concept.

Therefore a 'chunk', if it exists, must be the output of a 'chunker' that must be engaged in 'chunking'. And chunking is certainly a secondary operation, performed for a secondary reason, with secondary concerns.

But an asset doesn't seem to be the output of anything, so it should be kept out of this confusion.

So the missing context is process-orientation.

If it is produced by bundling, its a bundle. So disambiguating 'chunks' requires only the agreeable definition of what 'chunking' is. When that is available, then we will know what a 'chunk' is.

Until then, let's all agree that no one knows, and everyone is imagining.