preface

This article gives a brief introduction to rollup, focusing on the following examples

A rollup profile

An overview of

Rollup is a module bundler for JavaScript which compiles small pieces of code into something larger and more complex, such as a library or application. It uses the new standardized format for code modules included in the ES6 revision of JavaScript, instead of previous idiosyncratic solutions such as CommonJS and AMD. ES modules let you freely and seamlessly combine the most useful individual functions from your favorite libraries. This will eventually be possible natively everywhere, but Rollup lets you do it today

Simply put, rollup can be packaged as a library or an application. Rollup is often used to package libraries, but I personally find it easier to use rollup compared to WebPack.

By and core configuration introduction

NPM install --global rollupCopy the code
// NPM install rollup --save-devCopy the code

input

File entry

output

File: indicates the output name
Format: Indicates the output format
  • iife

    An autoexecute feature introduced using script

  • amd

    Asynchronous module definition for module loaders such as RequireJs

  • cjs

CommonJs works with Node and Browserify/Webpack

  • umd

    Common module definition, amd, CJS and IIFE as one

  • es/esm

    The output is an ES module, which can be introduced via the heading

  • system

SystemJs loader format

export default {
  input: 'src/main.js',
  output: {
    file: 'bundle.js',
    format: 'cjs'
  }
};
Copy the code

This is a very simple rollup.config.js file that can be run directly after rollup is installed

rollup -c rollup.config.js/rollup --config rollup.config.js 
Copy the code

Big-list-of-options rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup rollup

Common plug-ins

@rollup/plugin-node-resolve

Node-resolve handles external dependencies, such as node_modules

@rollup/plugin-commonjs

Commonjs converts common JS modules to ES6

@rollup/plugin-babel

Babel compiles files with Babel. When configuring Babel, you need to create.babelrc in the project root directory

// .babelrc
{
 "presets": [
   ["@babel/env", {"modules": false}]
 ]
}
Copy the code

rollup-plugin-terser

Terser, terser compression

rollup-plugin-uglify

Uglify, compressed with UglifyJS

@rollup/plugin-typescript

Typescript for seamless integration between rollup and typescript

Other connections about rollup

A rollup plug-in library

learn-rollup

A rollup. Js’s official website

To combat

Case a

// rollup.config.js import resolvePlugin from "rollup-plugin-node-resolve"; import babelPlugin from "rollup-plugin-babel"; import typescript from "@rollup/plugin-typescript"; import commonjs from "@rollup/plugin-commonjs"; import { uglify } from "rollup-plugin-uglify"; Export default [{input: "packages/index.ts", output: {file: "core.umd.js", // Export file format: "umd", // Supported format of package file name: "core", }, plugins: [ resolvePlugin(), typescript(), commonjs(), babelPlugin({ exclude: "node_modules/**", runtimeHelpers: true, }), uglify() ], } ];Copy the code

Then add it to the script below package.json

"scripts": {
    "clear": "rimraf lib",
    "build": "rollup -c rollup.config.js",
    "build:watch": "rollup -c rollup.config.js --watch",
    "build:prod": "cross-env NODE_ENV=production rollup -c rollup.config.js"
  }
Copy the code

I tried to output different formats to see the difference

Umd (common practice for libraries today)

iife

amd

cjs

The above is uncompressed, and for some reason the code is not very convenient to put out in its entirety

Case 2

I wanted to use the native way to write a library and send a NPM package, so I tried to use jquery

Results show

Main code

This code is similar to the output UMD format mentioned above, except that I’ve introduced jquery. If script is introduced, then jquery must be introduced in the code, because it is the last else, mounted globally

(function (g, fn) { if (typeof require ! == "undefined") { if (g.$ === undefined) { g.$ = require("./jquery.min.js"); } } var $ = g.$; if (typeof define === "function" && define.amd) { define(function () { return fn($); }); } else if (typeof module ! == "undefined" && module.exports) { module.exports = fn($); } else { g.Tab = fn($); } }(typeof window ! == "undefined" ? window : This, function($) {var Tab = function(container,options){// container is the id of the mount, } tab. prototype = {//} return Tab}Copy the code

A rollup packaging

import { uglify } from "rollup-plugin-uglify"; Export default [{input: "lib/tab.js", output: {file: "tab.min.js", // Export file format: "umd", // Supported format of package file name: "tab", }, plugins: [ uglify() ], } ];Copy the code

A compressed plug-in is used here.

Hit the pit

Error: new Tab () cannot be found. The solution is to create a new index.js file

module.exports = require('./lib/tab.min.js');
Copy the code

Json main lib/tab.min.js is changed to index.js. Then I realized that rollup wasn’t necessary at all, because I had written all the code in detail, so I could just change the entry to lib/tab.js

2, the release of NPM report encountered 2FA authentication two-factor authentication, Chorme installed an authentication plug-in

3. Note that the NPM package is specified as public when you publish it

npm publish --access=public
Copy the code

tip

Companies usually build private servers. If you don’t want to release public packages and test on a small scale, you can use NPM Link. Now that you have NPM link in your library, use the NPM Link + package name in your project to refer to the 3 methods of NPM private module

Everyone to laugh at the source address

Specification COMMIT & Release relase version

Since I was writing an NPM package for the first time, I used some plug-ins under commit to standardize my own commit, which is basically what well-known open source libraries do.Let me summarize what tools I used

Submit information using the Husky + CommLint specification

1, install,

npm install husky --save-dev
npm install --save-dev @commitlint/cli @commitlint/config-angular
Copy the code

2, configuration,

Add the following configuration under package.json,

"husky": { "hooks": { "pre-commit": "echo checking commit msg..." "Commit - MSG ": "Commitlint-e HUSKY_GIT_PARAMS" // HUSKY_GIT_PARAMS is an environment variable, which is the commit message // Commitlint is checking}},Copy the code

In addition to adding configuration in packge.json. You can also

3, commlint

Is a commit standard detection tool, according to the Conventional Commit format defined. I’ve found this to be very important to follow, especially in large factories and when writing open source libraries

# feat. Feat. # feat. Feat. # feat. # feat. # feat. # feat. # feat. Git refactor is used in refactoring to add a test or modify an existing test perf. Ci: Changes to chore related to CI (Continuous Integration Services) : do not modify the remaining modifications of SRC or test, such as changes to the build process or ancillary toolsCopy the code

This comes from the Git Commit Message specification. It seems that some open source libraries use ICONS to do so

4. A brief introduction to commitLint rules

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
Copy the code
  • Type is a screenshot of point 3
  • Scope is the return of a modification, for example
fix(src): fix login bug
Copy the code
  • Description is the COMMIT information
  • Both the body and footer are optional, and the body is a detailed description of the commit, describing the code commit details. Footer commit is incompatible change or close defect, footer must, otherwise can be omitted

5. Commit configuration

A new file is created for commitlint.config.js

// commitlint.config.js module. Exports = {// Extends: ["@commitlint/config-angular"], // custom rules: { 'type-enum': [2, 'always', [ 'upd', 'feat', 'fix', 'refactor', 'docs', 'chore', 'style', 'revert', ]], 'header-max-length': [0, 'always', 72] } };Copy the code

6. Verify the results

  • fails

  • success

7. Recommended reading

husky

commitlint

This section describes some commit scenarios

conventionalcommits

Presents the specification

Git commit specification

From Commit normalization to publishing custom CHANGELOG templates

usestandard-versionCHANGELOG is automatically generated

1, install,

npm i --save-dev standard-version
Copy the code

2, configuration,

// package.json
"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "rollup -c rollup.config.js",
    "release": "standard-version"
  },
Copy the code

3, run,

npm run release
Copy the code

4. Make a tag

git push --follow-tags origin master
Copy the code

Note that tags are generated by themselves and version is updated in package.json. You can also run NPM publish to NPM

5. Release a release

The first stepThe second step

4. Recommended reading

standard-version

Git Commit specification validation configuration and release configuration

conclusion

It uses plug-ins such as Husky, CommitLint, and standard-Version to normalize submitted logs and automatically generate CHANGELOG, as well as a more powerful tool, Commitizen. Tools, their own habits and apply to the actual situation of the project

The article is a little long, unavoidably there are omissions, please timely and correct, so as not to mislead others