How to use external module in webpack

This article mainly introduces the specific use of the webpack external module. Now I will share it with you and give you a reference.

This article discusses an option external that is often used when Webpack packages libraries. It is used to avoid packaging some very common modules into the library you publish, and instead chooses to declare them as external. Module, after your library is used by the upper layer, Webpack will package the external dependent modules in the final stage.

The external option is generally used for packaging libraries. If it is not a library but a final app release JS file, then external has no meaning. Regarding the analysis of the Webpack packaging library and the role of some options, I discussed it in the previous article.

external option

We still use the example from the previous article to define a library util.js:

import $ from 'jquery'

function hideImages() {
 $('img').hide();
}

export default {
 "hideImages": hideImages
}

We use Webpack to package and publish this Library:

// 入口文件
entry: {
 util: './util.js',
}

// 输出文件
output: {
 path: './dist',
 filename: '[name].dist.js'

 library: 'util',
 libraryTarget: commonjs2,
 targetExport: 'default'
}

The util.dist.js file packaged in this way will completely inject the jquery code into it, because your source code uses it. But this is often not what we want, because jquery is a very common module. In an app, other libraries may also use it. The top-level entry file app may also use it. If every library module All released versions package jquery into its own bundle intact, and finally put it together. There will be many copies of jquery in the final app release code. Of course, this may not affect its normal function. But it will occupy a large code size.

So usually when your library needs to depend on common JS modules such as jquery and bootstrap, we can not package it into a bundle, but declare external in the Webpack configuration:

externals: {
 jquery: {
  root: 'jquery',
  commonjs: 'jquery',
  commonjs2: 'jquery',
  amd: 'jquery',
 },
},

This is telling Webpack: Please do not inject this module into the compiled JS file. Please keep any import/require statements of this module that appear in my source code.

We can take a look at the structure of the compiled bundle file:

module.exports = (function(modules) {
 var installedModules = {};
 function webpack_require(moduleId) {
   // ...
 }
 return webpack_require('./util.js');
}) ({
 './util.js': generated_util,
 // '/path/to/jquery.js': generated_jquery 原本有这一行，现在被删去。
});

You can see that the jquery module is not packaged into the bundle file, and for util, its generated code is the generated_util function. Statements related to import jquery have also retained their original meaning:

function generated_util(module, exports, webpack_require) {
 var $ = require('jquery');
 // util的其它源代码
 // ...
}

Of course, it is not completely unmodified. For example, the import is changed back to the traditional require keyword, because we are using the CommonJS style packaging method here. But these are minor. The key is that it retains the keyword require and does not use webpack_require to really introduce jquery. This means that there is no jquery in the current module management system of this JS file. It is an external module. jquery can only be really introduced when this JS file is referenced by others and compiled at the upper level. At that time, the require keyword here will be replaced by webpack_require.

For external dependent modules, you can usually do this. For example, if you use npm to publish your library, you can add jquery to dependencies in the package.json file, so that when others npm install the library you published, , jquery will also be automatically downloaded to node_modules for others to package and use.

Packaging in umd format

If we use umd format packaging, we can see how the external module functions in different environments:

(function webpackUniversalModuleDefinition(root, factory) {
 if(typeof exports === 'object' && typeof module === 'object') // commonjs2
  module.exports = factory(require('jquery'));
 else if(typeof define === 'function' && define.amd)
  define("util", ['jquery'], factory); // amd
 else if(typeof exports === 'object')
  exports["util"] = factory(require('jquery')); // commonjs
 else
  root["util"] = factory(root['jquery']); // var
}) (window, function(__webpack_external_module_jquery__) {
 return (function(modules) {
  var installedModules = {};
  function webpack_require(moduleId) {
    // ...
  }
  return webpack_require('./util.js');
 }) ({
  './util.js': generated_util,
 });
}

And generated_util Also add a parameter __webpack_external_module_jquery__ accordingly:

function generated_util(module, exports, webpack_require,
            __webpack_external_module_jquery__) {
 var $ = __webpack_external_module_jquery__;
 // util的其它源代码
 // ...
}

This way of writing seems to have a different structure from the compiled version of CommonJS above, but in fact the essence is the same. Because umd now needs to take care of different operating environments, it advances require('jquery') and passes it in as a parameter of the factory. For each operating environment, each has its own approach:

1. CommonJS: Keep the require('jquery') statement.

2. AMD: Define jquery as a dependent module in define.

3. Var: Take out the jquery variable from the global domain, which requires jquery to be loaded before the module.

Then no matter what the situation is, they will pass the loaded jquery module as a parameter into the factory function, so that the util module can be loaded correctly.

The above part involving Webpack generated code may be a bit convoluted. You need to have a better understanding of the mechanism and principles of Webpack packaging modules. I have discussed this part in detail in this article.

Summary

The above is about the use of the external option of Webpack, and analyzes how it works from the compiled JS code. I think it is still very important to read the generated code related to Webpack, so that you can truly understand the external mechanism and know how to debug when you encounter some pitfalls.

The above is what I compiled for everyone. I hope it will be helpful to everyone in the future.

Related articles:

Example of defining your own angular time component based on datepicker

Solution to Vue.js 2.0 sometimes going both ways The problem of failure to bind img src attribute

Vue.js dynamically assign value to img’s src

The above is the detailed content of How to use external module in webpack. For more information, please follow other related articles on the PHP Chinese website!