Shulou(Shulou.com)06/03 Report--

This article mainly shows you "how to use webpack to build a library", the content is easy to understand, clear, hope to help you solve your doubts, the following let the editor lead you to study and learn "how to use webpack to build a library" this article.

Output product

The biggest difference between building a library and building a general application is the output product after the construction is completed.

Generally speaking, when the application is built, it will output:

A html file

One js entry chunk, several sub-chunk

Several css files

Several other resources, such as pictures, font files, etc.

Although the output of resources is very large, but in fact all the dependencies and loading relationships have been determined layer by layer from the beginning of the html file, in other words, the html file is actually the entrance to the whole application.

When a library is built, it outputs:

A js file in CommonJS format

An uncompressed js file in UMD format

A compressed js file in UMD format

May include several css files

May include several other resource files

The entries to the library are the js files listed above; you may wonder how a library has three entry files. Don't worry, just listen to me one by one.

CommonJS

CommonJS is a modular specification implemented by Node.js, and the main syntax includes module.exports, require (), etc.; and when we introduce npm packages using webpack, we are actually in the Node.js environment, so we can see that this CommonJS format entry js file (.common.js) is used by other applications to introduce npm packages in the Node.js environment. Because the volume of the npm package is generally not taken into account when referencing the npm package (it can be compressed by itself if necessary when building your own application), and in order to facilitate debugging, the js entry file is not compressed.

UMD

UMD is a hodgepodge of modular specifications. In addition to being compatible with CommonJS, it is also compatible with AMD modular specifications and the most traditional global variable patterns.

Here is a brief introduction to the AMD specification, the full name of AMD is Asyncchronous Module Definition, which is generally used on the browser side (which is the biggest difference from the CommonJS specification). The most famous AMD loader is RequireJS. At present, due to the popularity of webpack, the modular scheme of AMD has gradually withdrawn from the market.

The global variable pattern is easy to understand, that is, the entry of the library is mounted on a global variable (such as window.xxx), and any location on the page can be accessed at any time, which belongs to the most traditional js plug-in loading scheme.

As you can see above, the entry js file in UMD format can be used either for scenarios that reference npm packages (uncompressed version, i.e. .umd.js) or directly for the browser side (compressed version, i.e. .umd.min.js).

How to build library files with different modularization specifications

Currently, webpack does not support generating multiple entry js files at the same time, so it needs to be built multiple times.

The key webpack configurations are:

CommonJS:output.libraryTarget: "commonjs2"

UMD:output.libraryTarget: "umd"

For UMD, we also need to set the global variable name, output.library: "LibraryName".

To compress the built file, the easiest way is to call the webpack command in CLI with the mode parameter, such as webpack-- mode=production;. This is because when the value of mode is production, webpack automatically enables UglifyJsPlugin to compress the source code.

Output version information

When I work for a company, the company is very dependent on third parties, and all third-party dependencies used in the project must be applied and approved before they can be used; and the application is accurate to a specific version. Unapplied software versions are also not allowed to be used. Some third-party dependencies do not reflect the publication number either in the content of the file or in the name of the file, which creates an obstacle for us to identify such third-party dependencies, which we need to learn from when developing our own libraries.

When building a library, we can use webpack to output the information of the library directly to the contents of the file. With this "identity information", users will feel at ease to use it.

The way to output library version information is to use webpack.BannerPlugin. The easiest way to use it is as follows:

Const pgk = require ('. / package.json'); const banner = `${pkg.name} ${pkg.description}\ n@version v$ {pkg.version} @ homepage ${pkg.homepage} @ repository ${pkg.repository.url}\ n (c) 2019 Array-HuangReleased under the MIT License.hash: [hash]`; / * webpack configuration * / {/ /. Other configuration plugins: [/ /... Other plugin configuration new webpack.BannerPlugin (banner);]}

The final result is:

/ *! vue-directive-window * Vue.js directive that enhance your Modal Window, support drag, resize and maximize. * * @ version v0.7.5 * @ homepage https://github.com/Array-Huang/vue-directive-window * @ repository git+ https://github.com/Array-Huang/vue-directive-window.git * * (c) 2019 Array-Huang * Released under the MIT License. * hash: dc6c11a1e50821f4444a * * / source map

If the user of the library uses it directly by loading your library in the browser, it is necessary to provide a source map file; this is because after your library has been built by webpack or even compressed, it is so different from the source code that it will be difficult for users to debug in the browser But if you can attach a source map to your library, the browser developer tool will call source map to help parse, and the user's debugging experience will be closer to debugging the library's source code.

The corresponding webpack is configured as follows:

/ / webpack configuration {/ /... Other configuration devtool: 'cheap-module-source-map'}

Webpack supports multiple types of source map. Different types of source map have different performance in terms of generation speed, supporting features (such as babel), debugging location offset, and so on. I only make recommendations here:

Development environment: cheap-module-eval-source-map

Production environment: cheap-module-source-map

For other types of source map, see the devtool section of the webpack official documentation.

Eliminate third-party dependence

Unlike ordinary applications, when developing libraries, we should try to avoid introducing third-party libraries (except for the tool chains used in the construction process), because these third-party libraries will increase the size of the libraries we write; it is likely that we write small functions with only a few hundred lines of code logic, but build a library of hundreds of k, then such a library does not make much sense.

But it is really difficult for us to avoid using third-party libraries, so what should we do?

/ / webpack configuration {/ /... Other configuration externals: {lodash: {commonjs: 'lodash', commonjs2:' lodash', amd: 'lodash', root:' _'}

After using the above configuration, the third-party library specified in the configuration (lodash in the example) will not be included in the library we built. Let's explain them one by one:

Both the commonjs and commonjs2 entries indicate that the user loads the npm package named lodash in a CommonJS manner when using the current library in the node.js environment.

The amd entry indicates that when the library is loaded and run in the browser, the library will attempt to load the AMD module named lodash in the way of AMD.

The root entry means that when the library is loaded and run in the browser, the library will attempt to take the global variable window._ (when loading lodash.js through the tag, lodash will inject itself into the global variable window._).

Externals configuration that is different from the general application

In a general application, you may see this externals configuration:

/ / webpack configuration {/ /... Other configuration externals: {lodash:'_'}}

Such externals configuration means that the global variable should be taken no matter what the environment. If you are currently in general application and are sure to have used to load specified third-party libraries (such as jQuery, Vue and other core libraries, it is very common to load them in this way), of course, you can use them directly; but as the authors of the library, we should provide a more relaxed and flexible way to use them.

Complete example of webpack configuration

Since building libraries with different modular specifications requires different webpack configurations (in fact, only slightly different) to build multiple times, this article only shows the simplest webpack configuration example for the scenario of building UMD format and compression. If you want to know how to more efficiently piece together webpack configuration, please see the webpack configuration file of the micro-schema-validator project:

/ / webpack.config.jsconst webpack = require ('webpack'); const pkg = require ('. / package.json'); / / use package.json as an information source const banner = `${pkg.name} ${pkg.description}\ n@version v ${pkg.version} @ homepage ${pkg.homepage} @ repository ${pkg.repository.url}\ n (c) 2019 Array-HuangReleased under the MIT License.hash: [hash]` Module.exports = {entry: `${_ dirname} / index.js`, devtool: 'cheap-module-source-map', output: {path:` ${_ dirname} / dist`, / / define the output directory filename:' micro-schema-validator.min.js', / / define the output file name library: 'MicroSchemaValidator', / / define the name of the global variable exposed to the browser environment libraryTarget:' umd' / / specify the modularization specification to follow}, / * exclude third-party dependencies * / externals: {lodash: {commonjs: 'lodash', commonjs2:' lodash', amd: 'lodash', root:' _'}}, module: {rules: [{test: / (\ .jsx |\ .js) $/ Loader: 'babel-loader', exclude: / (node_modules | bower_components) /}, {test: / (\ .jsx |\ .js) $/, loader:' eslint-loader', exclude: / (node_modules | bower_components) /}]}, plugins: [new webpack.BannerPlugin (banner) / / output project information]} Customize and manage webpack configuration with vue-cli

For Vue ecological libraries, such as Vue components, Vue custom instructions, etc., you can use vue-cli (this article specifically refers to the version after vue-cli 3.0) to customize the webpack configuration according to your needs. The customized contents include:

Whether to enable Babel

Whether to access TypeScript syntax or not

Whether PWA is supported

Whether to use Vue-Router and Vuex

Whether or not to use CSS preprocessors, and you can choose specific CSS preprocessors, including Sass / Less / Stylus

Whether to use ESLint and Prettier

Whether to access unit testing and end-to-end testing (E2E)

After customization, vue-cli will generate a seed project that can be executed (including packages for local development and building production environments) but has no actual content (it's up to you to write the actual content). Compared with general scaffolding tools, in addition to generating webpack configurations, vue-cli will continue to manage and maintain them, such as:

Provide an entrance to a unified custom configuration; in the past, in order to achieve the purpose of custom configuration, we used to directly modify the webpack configuration generated by the scaffolding tool, which would lead to scattered modification points, making it difficult for custom webpack configurations to be reused in other projects. After using vue-cli, all the modification points to the webpack configuration are managed centrally, and if you need to reuse, you can directly migrate the custom configuration file (vue.config.js) to another project.

Provide a mechanism for continuously updating the webpack configuration; if I now have an open source library and I modify the library source code arbitrarily in order to achieve my own purpose, it will be difficult for me to upgrade the open source library because it will overwrite all my previous changes In the same way, because vue-cli unifies the entry for custom configuration and dynamically renders the webpack configuration every time the project is run (the project is also run through the command of vue-cli rather than webpack), the webpack configuration of the project can be upgraded with the upgrade of vue-cli.

Provides a mechanism for continuously updating the webpack tool chain As we all know, the webpack toolchain contains a large number of third-party open source libraries, such as Babel, ESLint, etc., these open source libraries are also constantly updated, in this process, Breaking Change will inevitably continue to be generated. Fortunately, vue-cli can adapt to the latest version of third-party open source libraries by upgrading itself and constantly modifying the webpack configuration. Our project can also get constant updates to the webpack tool chain at a minimal cost (upgrading vue-cli itself).

Vue-cli Custom configuration exampl

Excerpt from the vue.config.js file of the vue-directive-window project:

Const webpack = require ('webpack'); const pkg = require ('. / package.json'); const banner = `${pkg.name} ${pkg.description}\ n@version v {pkg.version} @ homepage ${pkg.homepage} @ repository ${pkg.repository.url}\ n (c) 2019 Array-HuangReleased under the MIT License.hash: [hash]`; module.exports = {chainWebpack: config = > {config.output.libraryExport ('default') Config.plugin ('banner') .use (webpack.BannerPlugin, [{banner, entryOnly: true,},]);},}

Does it look more concise than the most basic webpack configuration above? When the structure of the project is gradually enriched, the gap will continue to widen.

These are all the contents of the article "how to build a Library with webpack". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.