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:
CommonJS: Keep the require('jquery') statement.
AMD: Define jquery as a dependent module in define.
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!

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics

Vue is an excellent JavaScript framework that can help us quickly build interactive and efficient web applications. Vue3 is the latest version of Vue, which introduces many new features and functionality. Webpack is currently one of the most popular JavaScript module packagers and build tools, which can help us manage various resources in our projects. This article will introduce how to use Webpack to package and build Vue3 applications. 1. Install Webpack

Introduction to Caddy Caddy is a powerful and highly scalable web server that currently has 38K+ stars on Github. Caddy is written in Go language and can be used for static resource hosting and reverse proxy. Caddy has the following main features: Compared with the complex configuration of Nginx, its original Caddyfile configuration is very simple; it can dynamically modify the configuration through the AdminAPI it provides; it supports automated HTTPS configuration by default, and can automatically apply for HTTPS certificates and configure it; it can be expanded to data Tens of thousands of sites; can be executed anywhere with no additional dependencies; written in Go language, memory safety is more guaranteed. First of all, we install it directly in CentO

Form validation is a very important link in web application development. It can check the validity of the data before submitting the form data to avoid security vulnerabilities and data errors in the application. Form validation for web applications can be easily implemented using Golang. This article will introduce how to use Golang to implement form validation for web applications. 1. Basic elements of form validation Before introducing how to implement form validation, we need to know what the basic elements of form validation are. Form elements: form elements are

Using Jetty7 for Web Server Processing in JavaAPI Development With the development of the Internet, the Web server has become the core part of application development and is also the focus of many enterprises. In order to meet the growing business needs, many developers choose to use Jetty for web server development, and its flexibility and scalability are widely recognized. This article will introduce how to use Jetty7 in JavaAPI development for We

First of all, you will have a doubt, what is frp? Simply put, frp is an intranet penetration tool. After configuring the client, you can access the intranet through the server. Now my server has used nginx as the website, and there is only one port 80. So what should I do if the FRP server also wants to use port 80? After querying, this can be achieved by using nginx's reverse proxy. To add: frps is the server, frpc is the client. Step 1: Modify the nginx.conf configuration file in the server and add the following parameters to http{} in nginx.conf, server{listen80

Face-blocking barrage means that a large number of barrages float by without blocking the person in the video, making it look like they are floating from behind the person. Machine learning has been popular for several years, but many people don’t know that these capabilities can also be run in browsers. This article introduces the practical optimization process in video barrages. At the end of the article, it lists some applicable scenarios for this solution, hoping to open it up. Some ideas. mediapipeDemo (https://google.github.io/mediapipe/) demonstrates the mainstream implementation principle of face-blocking barrage on-demand up upload. The server background calculation extracts the portrait area in the video screen, and converts it into svg storage while the client plays the video. Download svg from the server and combine it with barrage, portrait

Web standards are a set of specifications and guidelines developed by W3C and other related organizations. It includes standardization of HTML, CSS, JavaScript, DOM, Web accessibility and performance optimization. By following these standards, the compatibility of pages can be improved. , accessibility, maintainability and performance. The goal of web standards is to enable web content to be displayed and interacted consistently on different platforms, browsers and devices, providing better user experience and development efficiency.

Cockpit is a web-based graphical interface for Linux servers. It is mainly intended to make managing Linux servers easier for new/expert users. In this article, we will discuss Cockpit access modes and how to switch administrative access to Cockpit from CockpitWebUI. Content Topics: Cockpit Entry Modes Finding the Current Cockpit Access Mode Enable Administrative Access for Cockpit from CockpitWebUI Disabling Administrative Access for Cockpit from CockpitWebUI Conclusion Cockpit Entry Modes The cockpit has two access modes: Restricted Access: This is the default for the cockpit access mode. In this access mode you cannot access the web user from the cockpit
