Why is Rollup better than WebPack for packaging libraries

preface

About a year ago, I wrote a small JS plug-in remember-Scroll and shared an article: Use Class to write a js plug-in to remember the user left the location, is a pure JS library, function is when the user enters the page again can automatically locate the last browsing location, using Webpack + Babel package, inside the Webpack and Babel configuration so far seems to be very typical.

There are a lot of front-end packaging tools out there — WebPack,gulp, Rollup, etc. There are a lot of articles on the web analyzing which scenarios they are better suited for. Webpack is better for packaging component libraries, applications and the like, while Rollup is better for packaging pure JS libraries. Therefore, the author has always had the idea to try to change the packaging tool of Remember-Scroll from Webpack to rollup, so as to compare the differences between the two from the perspective of practical application.

Rollup from zero configuration

1. Install rollup and some plug-ins

npm i rollup rollup-plugin-uglify rollup-plugin-filesize @rollup/plugin-node-resolve @rollup/plugin-commonjs -D
Copy the code

• rollup-plugin-uglifyUsed to compress obfuscated packed JS.
• rollup-plugin-filesizeDisplay the file size on the console after packaging.
• @rollup/plugin-node-resolveletrollupA third-party module that recognizes node_modules.
• @rollup/plugin-commonjsConvert CommonJS modules to ES2015 suppliesrollupTo deal with.

2. Add the Babel

npm i @rollup/plugin-babel @babel/core @babel/plugin-transform-runtime @babel/preset-env core-js@2 -D
Copy the code

• @rollup/plugin-babelRollup’s Babel plugin.
• @babel/coreBabel core.
• @babel/plugin-transform-runtimeUsed to avoid contaminating global functions (not required, but preferably as a class library).
• @babel/preset-envThe relevant polyfills are automatically injected based on the target browser.
• core-jsPolyfill’s library, which is using version 2.x (using 3 increases the package size).

Babel.config.js in the root directory is as follows:

const presets = [
  [
    '@babel/env',
    {
      useBuiltIns: 'usage'.corejs: { version: 2}},]]const plugins = [
  '@babel/plugin-transform-runtime'
]

module.exports = { presets, plugins }
Copy the code

3. Create one in the root directoryrollup.config.js, all configurations are as follows:

import filesize from 'rollup-plugin-filesize'
import babel from '@rollup/plugin-babel'
import resolve from '@rollup/plugin-node-resolve'
import { uglify } from 'rollup-plugin-uglify'
import commonjs from '@rollup/plugin-commonjs'

const isProd = process.env.NODE_ENV === 'production'

export default {
  input: 'src/index.js'.output: {
    file: isProd ? 'dist/remember-scroll.min.js' : 'dist/remember-scroll.js'.format: 'umd'.exports: 'default'.name: 'RememberScroll',},plugins: [
    resolve(),
    commonjs(),
    filesize(),
    babel({ babelHelpers: 'runtime'.exclude: ['node_modules/**'] }),
    (isProd && uglify())
  ]
}
Copy the code

4. package.jsonThe package command is as follows:

    "build": "rollup -c --environment NODE_ENV:production && rollup -c",
    "dev": "rollup -c  --watch",
Copy the code

In short, everything is configured the same as the previous Version of WebPack, using Babel. NPM Run build can pack resources into DIST. Let’s compare the size of webpack and rollup.

Webpack vs. Rollup package volume comparison

The author specially built a branch with resources packed by rollup and Webpack at the same time. You can directly look at the memor-Scroll /dist of feature/webpack_rollup branch on Github, and the comparison results are as follows:

As you can see, the size of the rollup package is slightly smaller than that of webpack. Looking at the package code, the webpack file contains many definitions of the __webpack_require__ utility functions and is not very readable, while the ROLLup js package is much simpler.

The master branch of the project has been changed to use rollup for construction, and the feature/ Webpack branch retains the previous configuration of Webpack. Interested students can go to Github for details.

I have to say that a rollup build is definitely more appropriate in terms of package size.

The package.json main points to the problem

One problem I encountered was whether package.json’s main should point to the built development version or production version.

This article provides an answer to the question of the main field in package.json: Main should point to the development version.

There is a question here: does the large size of the reference development package make my application packaged in a large release version?

To verify that the package.json main above points to development or production versions, I will do a direct comparison here.

Create a VUE project using VueCli V4.5.9, then introduce Remember-Scroll packaged by different tools in app. vue, and then NPM Run build to package the Vue project, and compare the volume of the packaged Chunk-Vendors.[hash].js.

By default, the imported NPM packages are packaged into chunk-VENDORS, and the incremental volumes of app.js are all the same, so don’t make any comparisons.

As you can see, for rollup packages, whether main points to development or production, the gzip package is almost the same, but for WebPack packages, main points to development will be very different in size.

NODE_ENV === ‘production’ refers to the compressed production version. For example, create a new index.js file in the root directory, with the package.json main pointing to it, and place it in js:

if (process.env.NODE_ENV === 'production') {
	module.exports = require('./dist/remember-scroll.min.js')}else {
	module.exports = require('./dist/remember-scroll.js')}Copy the code

This is especially important if you are writing a plug-in packaged with WebPack in the future.

If you pack it with rollup, you don’t have to worry about this detail, because rollup smells better than Webpack.

conclusion

Rollup is more suitable than Webpack for remember- Scroll js library under the condition that functions remain the same and browser compatibility is consistent. So if we want to make technology selection in the future, for pure JS library, choose to use rollup will be more appropriate.

Of course, rollup and WebPack are both build tools, and they have their own advantages and their own usage scenarios, so take advantage of them.