Talking about a WebPack build speed optimization misunderstanding

Problem Description A NPM package A is used in the project. I have been using it well a few days ago, I suddenly pulled another branch code after a certain time.

The first reaction is that someone changed the version of this package. View the


package.json , package-lock.json file, the information of the module and the dependency module did not change, Node_Modules / a Version information is also corresponding to package.json .

didn’t look at the clue at once, I have to debug it in Node_Modules.


Pull to the final look at summary XD

Node_Modules directory structure

item Node_Modules The directory is as follows:

Node_Modules│ └ – ─ │ │ │ │ └───── Node_Modules│ │ … │ └ – ─ C | | Index.js | | … │ └ – ─ │ │ │ │ …

  From this directory structure, it can be found that there is another  node_modules 
directory in the directory of the module A. This directory is placed on the function of module A. The classmate of the eye may find that the module C is installed in the Node_Modules directory and
A module’s Node_Modules

directory of the A module. Why is this? There are 2: project directly dependent module c

c item does not depend directly on the module, but the module project depend directly dependent modules b c, and you and a c-dependent version of the module is not compatible.

  1. our project did not directly reference the module c, it is the second case.
  2. NPM module mounting mechanism

This section explains why the item is not directly dependent module c, it will node_modules c installed in the directory of the project. Interested students can not skip.

Suppose a project depends on the module and the module b, c of the modules a dependent module Version 1.0.0, 2.0.0 dependent module b c of the module.


In NPM2 when used in a nested fashion to the mounting module, module C are mounted to the a and b node_modules directory module.

Although this method is simple, but can lead to a large number of identical modules in the presence node_modules. Imagine if a module and the module dependent module c is version 1.0.0, using this approach will produce redundant modules.

浅谈一个webpack构建速度优化误区 npm3

When the npm3, where npm2 generated redundancy module is improved. When the module will try to install npm install the module to the outermost node_modules directory, so that modules can be reused as much as possible.

When installing the module, if not the same name as the outer node_modules directory module, it will be mounted to the outermost ndoe_modules directory

If the outer node_modules directory of the same name already exists module, and the version is compatible, it is no longer mounted (directly using the outer modules)

    If the outer node_modules directory of the same name already exists in the module, and the version is not compatible, then in the parent module mounting nod
  1. The installation module of the above case

quoted modules



node_modules / a / node_modules / c / index.js plus some logs, found that there is no implementation! ?

To this step, or the location of the log is not written, or it is not introduced into this module. After confirming that

resolve.mainfields attributes and module C package.json

file information is excluded, the first possibility is excluded.

Tips: resolve.mainfields The attribute is used to tell WebPack, how to find the entry of this module when introducing an NPM module. At this time, it has been a bit. Isn’t the first level first level first level first level in the current directory in the node_modules directory? Speaking up to look up, then try it in the Node_Modules directory of the previous level.

Sure enough! Quote is the module C in the outermost Node_Modules! Is the WEBPACK lookup module different from node.js? Or is it because some configurations of WebPack caused?

Use the following WebPack configuration to be built, and there is no above problem.

const path = required (‘path’) module.exports = {entry: ‘./src/index.js’, Output: {filename:’ main.js ‘, Path: path.resolve (__ DiRName,’ ./dist/js’)}};

That takes down as long as it is investigated which WebPack configuration affects module retrieval. View the WebPack configuration in the project, and the module retrieval related only
Resolve property.
   Const config = {resolve: {modules: [PROJECTDIR, 'SRC'), Path.Resolve (Projectdir, 'Node_Modules'), Path.Resolve (IMTPATH, 'NODE_MODULES'),], // ES Tree-Shaking Mainfields: ['JsNext: Main', 'Browser', 'Main'], Alias: {}, extensions: ['.jsx', '.js '] 
Fortunately, for the WebPack document, soon found questions:

Absolute path. The following is the content of the WebPack document: tells the webpack to resolve the module.

The absolute path and relative path can be used, but it is necessary to know a little difference between them.
By looking at the current directory and ancestral path (ie ./node_modules, ../node_modules, etc.), the relative path will look similar to Node Find ‘Node_Modules’.
  Use an absolute path to search only in a given directory.  
In the above WebPack configuration, path.resolve (Projectdir, ‘Node_MODules’)
For the project’s node_modules directory. The reason for this is because the result of optimizing the speed of the module retrieval, resulting in such a serious bug.

According to the WebPack document, this is because this absolute path leads to bugs. Then just replace this absolute path to node_modules

, bug is solved.

When the module is installed, the outermost layer is installed in the Node_Modules directory, unless conflict is installed to the Node_Modules under the parent module. middle.

in the WebPack configuration is set to the absolute path of the project node_modules directory, resulting in WebPack when looking for the Node_Modules directory, only in the outermost directory lookup, ignoring the deeper’s same name module. This is in contrast to the default lookup policy “Priority Use Deep Modules”, causing an error of the NPM package when constructing.

The above is all the content of this article, I hope to help everyone, I hope everyone will support Tumi Cloud.

© Copyright Notice
Just support it if you like
comment Grab the couch

Please log in to comment