Preface: The following is my own summary, more or less there will be mistakes, if there are mistakes, I hope to point out the concept of front-end modularity before we talk about Webpack

1. Front-end modularization

  • Why front-end modularity is needed:

The problem with namespaces is that without modularization, variable names and method names in code can easily be overwritten by users without their knowledge, which can cause problems. It’s difficult to manage because without modularity, it’s very important to manage your code if you load only through script tags, there are restrictions on the order in which you load first, some dependencies have to be written after the dependencies, and there are so many scripts that if something goes wrong with one of them, The scripts that follow are not loaded.

The earliest approach to modularity was to have a single object that defined all the attributes needed. This solved the namespace problem to some extent, but others could change your property names at will.

After the modular solution is to use closures, through the closure of IIFE, you can effectively create private attributes, you can set some attributes that do not need to be exposed to the outside world to private, only the need to be exposed to the outside world to return the variable to accept. The advantage is that naming conflicts are resolved, but outsiders can modify the internal code.

In a word, modular development facilitates code management, improves code reuse and reduces code coupling. Each module will have its own scope

  • Now the mainstream modular approach:

    • Commonjs: The CommonJS specification is implemented specifically by Node.js.

      Features: because it is used in the server side, so it only realized the synchronous loading module. The exported module is a shallow copy, and once exported, subsequent changes in the module will not affect the exported code. CommonJS import supports dynamic import: require(${path}/xx.js);

      Disadvantages: Traditional CommonJS implementations cannot be used on the browser side because node.js modules are stored on disk and are very fast when loaded synchronously. However, for the browser side, the module is saved on the server, so the synchronous loading will inevitably lead to the problem of the browser death.

    • AMD

    • CMD

    • ES6 Module: The first ES6 Module is the modular way proposed by ECMA, but not the folk spread of these ways. It’s very simple to use. Features: The value exported by ES6 modules is the address of the module’s memory, so if the module code changes, the exported location will also change. The ES6 module is a compile-time output interface. The JS engine generates only a read-only reference to the memory address of the module object when it encounters an import command during static analysis of the script. When it comes time to actually execute, get the specific value from the reference.

  • Commonjs and Es6 MOdules
    • CommonJS is loaded synchronously while ES6 Modules are loaded asynchronously;
    • CommonJS exports a copy of the value, while ES6 Module is a reference to the exported value. And the variables received cannot be reassigned will be handled differently for loop dependencies;
    • CommonJS can load dynamically using template strings, but ES6 Modules cannot

2.Webpack:

Webpack takes the project as a whole, starts to find all the dependent files of the project through a given entry file, uses loader to process them, and finally packages them into one or more browser-recognized JS files, which is basically a packaging tool

Webpack build process:

1. Initialization parameters: read and merge parameters from configuration files and Shell statements to obtain the final parameters;

2. Start compiling: Initialize the Compiler object using the parameters obtained in the previous step, load all the configured plug-ins, and execute the object’s run method to start compiling

3. Determine the entry: Locate all entry files according to the entry in the configuration.

4. Module compilation: Starting from the entry file, call all configured Loader to translate the module, find out the module that the module depends on, and then recurse this step until all the entry dependent files have gone through this step;

5. Complete module compilation: After using Loader to translate all modules in Step 4, obtain the final content of each module after translation and the dependencies between them;

6. Output resources: Assemble chunks containing multiple modules one by one according to the dependency between the entry and modules, and then convert each Chunk into a separate file and add it to the output list. This step is the last chance to modify the output content.

7. Output complete: After determining the output content, determine the output path and file name based on the configuration, and write the output content to the file system.

In the above process, Webpack will broadcast a specific event at a specific point in time, the plug-in will execute a specific logic after listening for the event of interest, and the plug-in can call the API provided by Webpack to change the running result of Webpack.

Plug-ins in WebPack

  • A Plugin is a Plugin. Plugin can extend the functionality of WebPack to make it more flexible. A number of events are broadcast during the life cycle of a Webpack run, and the Plugin can listen for these events and change the output when appropriate through the API provided by Webpack
  • Common plug-ins are htMl-webpack-plugin, ugligy-webpack-plugin, which are configured separately in plugins. Each item is an instance of plugin, and the parameters are passed in through the constructor.

Loader in webpack

  • Loader is a Loader. Webpack treats all files as modules, but Webpack natively only parses JS files, and if you want to package other files, you use loader. So what Loader does is give WebPack the ability to load and parse _ non-javascript files.
  • Common csS-loader,style-loader,file-loader,url-loader, babel-loader, loader is configured in module.rules, that is to say, it exists as the parsing rule of the module. The type is array, each item is an Object, which describes the type of file (test), what to use (loader), and the parameters (options) to use.

What are bundles, chunks, and modules?

  • Bundle: Files packaged by Webpack
  • Chunk: a chunk is a code block. A chunk is composed of multiple modules for merging and splitting codes
  • Module: is a single module under development. In the WebPack world, everything is a module, one module corresponds to one file, and WebPack will recursively find all dependent modules starting from the configured entry