Babel Tutorial For Beginners 2019

What is Babel?

Babel Tutorial from Coding compiler. Babel or Babel.js is a free and open-source JavaScript compiler and configurable transpiler used in web development. Let’s start learning Babel with code examples.

Babel is a JavaScript compiler

Babel is a toolchain that is used to convert ECMAScript 2015+ code into a backward compatible version of JavaScript code in an older browser or environment:

  • Conversion syntax
  • Polyfill implements missing features in the target environment (via @babel/polyfill )
  • Source code conversion (codemods)
 // Babel Input: ES2015 arrow function
[1, 2, 3].map((n) => n + 1);

// Babel Output: ES5 equivalent
[1, 2, 3].map(function(n) {
 return n + 1;
});

For a great tutorial on compilers, check out the Super Micro Compiler, which explains how Babel itself works in high-level languages.

ES2015 and others

Babel supports the latest version of JavaScript through a syntax converter.

These plugins allow you to use the new syntax now without waiting for browser support. Check out our usage guide to get started.

JSX and React

Babel can convert JSX syntax! Check out the React preset to get started. And babel-sublime use with syntax highlighting can be elevated to a whole new level.

You can install the preset by the following command

npm install --save-dev @babel/preset-react

And @babel/preset-react added to your Babel configuration.

 export default React.createClass({
 getInitialState() {
   return { num: this.getRandomNumber() };
 },

 getRandomNumber() {
   return Math.ceil(Math.random() * 6);
 },

 render() {
   return <div>
     Your dice roll:
     {this.state.num}
   </div>;
 }
});

Learn more about JSX .

Type annotations (Flow and TypeScript)

Babel can delete type annotations! Check the Flow preset or TypeScript preset to get started. Note that Babel does not perform type checking ; you can still install Flow or TypeScript for type checking.

You can install the flow preset by using this command.

npm install --save-dev @babel/preset-flow
// @flow
function square(n: number): number {
 return n * n;
}

You can also install the typescript preset with this command.

npm install --save-dev @babel/preset-typescript

function Greeter(greeting: string) {
   this.greeting = greeting;
}

Learn more about Flow and TypeScript .

Pluggable

Babel is built with plugins. You can use your existing plugins to write your own conversion pipeline or write your own plugins. Easily use a set of plugins by using or creating a preset .

Use astexplorer.net to dynamically create plugins or use generator-babel-plugin to generate plugin templates.

// A plugin is just a function
export default function ({types: t}) {
 return {
   visitor: {
     Identifier(path) {
       let name = path.node.name; // reverse the name: JavaScript -> tpircSavaJ
       path.node.name = name.split('').reverse().join('');
     }
   }
 };
}

Debuggable

Source map is supported , so you can easily debug compiled code.

Normative

Babel tries to follow the ECMAScript standard as much as possible. In order to balance performance, it may also have specific options to make it more compliant.

Compressibility

Babel tries to use as little code as possible without relying on a large runtime environment.

Some situations can be difficult to achieve, so to ensure readability, file size, and (running) speed, some compliance is sacrificed for a particular conversion, providing the “loose” option.

Babel Usage

There are many tools in the Babel toolchain that make it easy to use Babel, whether you are an “end user” or a Babel in your build. This article is a quick guide to using these tools, and you can read more about them in the Usage section of the documentation.

If you are using a framework, the way different frameworks configure Babel may be different, and in fact some frameworks are already configured for you. Please refer to the interactive setup guide for the specific configuration method .

Overview

This article will show you how to compile JavaScript code that uses the ES2015+ syntax into code for the current browser. This will involve converting the new grammar and implementing missing features.

The entire configuration process includes:

Use the following command to install packages:

npm install --save-dev @babel/core @babel/cli @babel/preset-env
npm install --save @babel/polyfill

Create a file named in the root directory of the project using the following babel.config.js profile:

const presets = [
 ["@babel/env", {
   targets: {
     edge: "17",
     firefox: "60",
     chrome: "67",
     safari: "11.1"
   },
   useBuiltIns: "usage"
 }]
];

> The browser list above is just an example of display purpose. You must adjust to the browser you want to support.

This command will run all the code from the src catalog compiled to lib:

./node_modules/.bin/babel src --out-dir lib

Copy

You can [email protected] npm package that comes with runner, with a npx babel replacement ./node_modules/.bin/babel to shorten the command.

Read on to get a step-by-step description of how it works and an introduction to each tool you use.

Basic usage of the CLI

All of the Babel modules you need will be released as a separate npm package, with a range @babel (starting with version 7). This modular design allows each tool to be designed for a specific use case. Let us look at @babel/core and @babel/cli.

Core library

The core functionality of Babel is in the @babel/core module. Install by the following command:

npm install --save-dev @babel/core

You can directly in JavaScript require it and so use it as follows:

const babel = require("@babel/core");
babel.transform("code", optionsObject);

As an end user, you may want to install other tools as @babel/corean interface, and can be well integrated in your development process. Even so, you may still need to check its documentation page for these options, most of which can be set by other tools.

CLI tool

@babel/cli is a tool that allows you to use babel from your terminal. The following are examples of installation commands and basic usage:

npm install --save-dev @babel/core @babel/cli
./node_modules/.bin/babel src --out-dir lib

It uses analytical methods we set up to resolve src all of the JavaScript files in a directory, and the output of each converted file to lib the directory. Since we haven’t set up parsing yet, the output code here will be the same as the input (the exact code style is not preserved). We can specify the way we want to parse by passing them as options.

We use the above –out-dir options. You can use –help it to view the remaining options cli tool accepts operation. But for us the most important thing is –plugins, and –presets.

Plugins & Presets

The code conversion comes in the form of a plugin, which is a small JavaScript program that tells Babel how to convert the code. You can even write your own plugin to apply whatever code conversion you want. To convert the ES2015+ syntax to ES5, we can rely on official plugins such as @babel/plugin-transform-arrow-functions:

npm install --save-dev @babel/plugin-transform-arrow-functions

./node_modules/.bin/babel src --out-dir lib [email protected]/plugin-transform-arrow-functions

Now all the arrow functions in our code will be converted to ES5 compatible function expressions:

const fn = () => 1;
// converted to
var fn = function fn() {
 return 1;
};

This is a good beginning! If you want to convert the code there are other ES2015+ features. Instead of adding all the plugins we want, we can use “preset” instead of a pre-set set of plugins.

Just like using plugins, you can also create your own presets and share any plugin combinations you need. In this example, we used env preset.

 npm install --save-dev @babel/preset-env
./node_modules/.bin/babel src --out-dir lib [email protected]/env

Without any configuration, this preset includes all plugins that support modern JavaScript (ES2015, ES2016, etc.). But presets can also be chosen. Instead of passing in the cli and preset options from the terminal, we pass another way of passing in the options: the configuration file.

Configuration

There are several different ways to configure the file, depending on your needs. Be sure to read about how to configure Babel in-depth guide for more information.

Now, let’s create a named babel.config.js file, which contains the following:

const presets = [
 [
   "@babel/env",
   {
     targets: {
       edge: "17",
       firefox: "60",
       chrome: "67",
       safari: "11.1",
     },
   },
 ],
];

module.exports = { presets };

Env Preset now only loads the conversion plugin for features not available in the target browser. Next we look at polyfills.

Polyfill

The @babel/polyfill module includes core-js and a custom regenerator runtime to simulate the full ES2015+ environment.

This means that you can use like Promise or WeakMap such new built-in functions, like Array.from or Object.assign such static methods as Array.prototype.includes instance methods such, as well as generator function (provided you use the regenerator plug-in). To do this, polyfill increase the global scope as well as String Native prototype like this.

For the author of the library/tool, it is too redundant. If you do not like Array.prototype.includes such an instance method, you can use the transform runtime plugin instead of global pollution @babel/polyfill.

Further, if you know exactly what you need to implement, you can get them directly from core-js .

Since we are building an app, we can just install @babel/polyfill:

npm install --save @babel/polyfill

Note that –save option instead –save-dev, because this is a polyfill run before the source code needed.

Fortunately for us, we are using a env preset, which has an “useBuiltIns” option, when set “usage”when, in fact, the last application optimization mentioned above, you need only include polyfill. With this new option, the configuration changes are as follows:

 const presets = [
 [
   "@babel/env",
   {
     targets: {
       edge: "17",
       firefox: "60",
       chrome: "67",
       safari: "11.1",
     },
     useBuiltIns: "usage",
   },
 ],
];

module.exports = { presets };

Babel will check all of your code to find missing features in the target environment and only include the polyfills you need. For example this code:

Promise.resolve().finally();

Will become this (because Edge 17 does not Promise.prototype.finally):

require("core-js/modules/es.promise.finally");
Promise.resolve().finally();

If we do not env preset the “useBuiltIns” setting options for “usage”, it is necessary to require the code before the other one full of polyfill.

Summery:

We used @babel/cli to run from the terminal Babel, @babel/polyfill to implement all new JavaScript function, env PRESET only contains the conversion functions we use to achieve our goals browser missing features.

Configuring Babel

Babel can be configured! Many other tools have similar configs: ESLint (.eslintrc), Prettier (.prettierrc).

All Babel API options are allowed. However, if the option requires JavaScript, you may want to use a Javascript configuration file.

What’s your use case?

  • You want to programmatically create the configuration?
  • You want to compile node_modules?
babel.config.js is for you!
  • You have a static configuration that only applies to your simple single package?
.babelrc is for you!
  • The Guy Fieri is your hero?

We recommend to use the babel.config.js format. Babel itself is using it.

babel.config.js

Create a file called babel.config.js with the following content at the root of your project (where the package.json is).

module.exports = function (api) {
 api.cache(true);

 const presets = [ ... ];
 const plugins = [ ... ];

 return {
   presets,
   plugins
 };
}

Check out the babel.config.js documentation to see more configuration options.

.babelrc

Create a file called .babelrc with the following content in your project.

{
 "presets": [...],
 "plugins": [...]
}

Check out the .babelrc documentation to see more configuration options.

package.json

Alternatively, you can choose to specify your .babelrc config from within package.json using the babel key like so:

 {
 "name": "my-package",
 "version": "1.0.0",
 "babel": {
   "presets": [ ... ],
   "plugins": [ ... ],
 }
}

.babelrc.js

The configuration is the same as .babelrc, but you can write it using JavaScript.

 const presets = [ ... ];
const plugins = [ ... ];

module.exports = { presets, plugins };

You are allowed to access any Node.js APIs, for example a dynamic configuration based on the process environment:

 const presets = [ ... ];
const plugins = [ ... ];

if (process.env["ENV"] === "prod") {
 plugins.push(...);
}

module.exports = { presets, plugins };

Using the CLI (@babel/cli)

babel --plugins @babel/plugin-transform-arrow-functions script.js

Check out the babel-cli documentation to see more configuration options.

Using the API (@babel/core)

require("@babel/core").transform("code", {
 plugins: ["@babel/plugin-transform-arrow-functions"]
});

Babel Code Editors – IDE For Babel

Syntax highlighting

Many popular editors now support ES2015+ syntax highlighting directly, while others require additional extensions. This guide will help you support syntax highlighting.

If you want more advanced integration, you can check out the installation guide.

Hint: The font used in the screenshot above is FiraCode .

Atom

Install the language-babel component and follow the instructions .

Sublime Text 3

First, install Package Control . Then install the Babel components from the Package Control menu and follow the instructions .

Vim

Install the vim-javascript plugin, which provides improved syntax highlighting and JavaScript indentation support for Vim.

Another approach is and es.next.syntax used together yajs.vim .

Visual Studio Code

Install the sublime-babel-vscode extension and follow the instructions.

There are other ways to support syntax highlighting, and you can learn more in the Visual Studio Code documentation .

WebStorm

WebStorm now supports ES2015+ without installing any additional extensions. However, you may need to enable him .

Plugins

Babel is a compiler (source code => output code). Like many other compilers it runs in 3 stages: parsing, transforming, and printing.

Now, out of the box Babel doesn’t do anything. It basically acts like const babel = code => code; by parsing the code and then generating the same code back out again. You will need to add plugins for Babel to do anything.

Instead of individual plugins, you can also enable a set of plugins in a preset.

Transform Plugins

These plugins apply transformations to your code.

Transform plugins will enable the corresponding syntax plugin so you don’t have to specify both.

ES3

  • member-expression-literals
  • property-literals
  • reserved-words

ES5

  • property-mutators

ES2015

  • arrow-functions
  • block-scoped-functions
  • block-scoping
  • classes
  • computed-properties
  • destructuring
  • duplicate-keys
  • for-of
  • function-name
  • instanceof
  • literals
  • new-target
  • object-super
  • parameters
  • shorthand-properties
  • spread
  • sticky-regex
  • template-literals
  • typeof-symbol
  • unicode-regex

ES2016

  • exponentiation-operator

ES2017

  • async-to-generator

ES2018

  • async-generator-functions
  • dotall-regex
  • named-capturing-groups-regex
  • object-rest-spread
  • optional-catch-binding
  • unicode-property-regex

Modules

  • modules-amd
  • modules-commonjs
  • modules-systemjs
  • modules-umd

Experimental

  • class-properties
  • decorators
  • do-expressions
  • export-default-from
  • export-namespace-from
  • function-bind
  • function-sent
  • logical-assignment-operators
  • nullish-coalescing-operator
  • numeric-separator
  • optional-chaining
  • pipeline-operator
  • throw-expressions

Minification

Check out our minifier based on Babel!

These plugins are in the minify repo.

  • inline-consecutive-adds
  • inline-environment-variables
  • member-expression-literals
  • merge-sibling-variables
  • minify-booleans
  • minify-builtins
  • minify-constant-folding
  • minify-dead-code-elimination
  • minify-flip-comparisons
  • minify-guarded-expressions
  • minify-infinity
  • minify-mangle-names
  • minify-numeric-literals
  • minify-replace
  • minify-simplify
  • minify-type-constructors
  • node-env-inline
  • property-literals
  • regexp-constructors
  • remove-console
  • remove-debugger
  • remove-undefined
  • simplify-comparison-operators
  • undefined-to-void

React

  • react-constant-elements
  • react-display-name
  • react-inline-elements
  • react-jsx
  • react-jsx-compat
  • react-jsx-self
  • react-jsx-source

Other

  • external-helpers
  • flow-strip-types
  • jscript
  • object-assign
  • object-set-prototype-of-to-assign
  • proto-to-assign
  • regenerator
  • runtime
  • strict-mode
  • typescript

Syntax Plugins

These plugins only allow Babel to parse specific types of syntax (not transform).

NOTE: transform plugins automatically enable the syntax plugins. So you don’t need to specify the syntax plugin if the corresponding transform plugin is used already.

Alternatively, you can also provide any plugins option from the Babel parser:

Your .babelrc:

{
 "parserOpts": {
   "plugins": ["jsx", "flow"]
 }
}

Plugin/Preset Paths

If the plugin is on npm, you can pass in the name of the plugin and babel will check that it’s installed in node_modules

{
 "plugins": ["babel-plugin-myPlugin"]
}

You can also specify an relative/absolute path to your plugin.

{
 "plugins": ["./node_modules/asdf/plugin"]
}

Plugin Shorthand

If the name of the package is prefixed with babel-plugin-, you can use a shorthand:

{
 "plugins": [
   "myPlugin",
   "babel-plugin-myPlugin" // equivalent
 ]
}

This also works with scoped packages:

{
"plugins": [
   "@org/babel-plugin-name",
   "@org/name" // equivalent
 ]
}

Plugin Ordering

Ordering matters for each visitor in the plugin.

This means if two transforms both visit the “Program” node, the transforms will run in either plugin or preset order.

  • Plugins run before Presets.
  • Plugin ordering is first to last.
  • Preset ordering is reversed (last to first).

For example:

 {
 "plugins": ["transform-decorators-legacy", "transform-class-properties"]
}

Will run transform-decorators-legacy then transform-class-properties.

It is important to remember that with presets, the order is reversed. The following:

{
 "presets": ["es2015", "react", "stage-2"]
}

Will run in the following order: stage-2, react, then es2015.

This is mostly for ensuring backwards compatibility, since most users list “es2015” before “stage-0”. For more information, see notes on potential traversal API changes.

Plugin Options

Both plugins and presets can have options specified by wrapping the name and an options object in an array inside your config.

For specifying no options, these are all equivalent:

 {
 "
plugins": ["pluginA", ["pluginA"], ["pluginA", {}]]
}

To specify an option, pass an object with the keys as the option names.

 {
 "plugins": [
   [
     "transform-async-to-module-method",
     {
       "module": "bluebird",
       "method": "coroutine"
     }
   ]
 ]
}

Settings options for presets works exactly the same:

 {
 "presets": [
   [
     "env",
     {
       "loose": true,
       "modules": false
     }
   ]
 ]
}

Plugin Development

Please refer to the excellent babel-handbook to learn how to create your own plugins.

The simple plugin that reverses names (from the homepage):

 export default function() {
 return {
   visitor: {
     Identifier(path) {
       const name = path.node.name;
       // reverse the name: JavaScript -> tpircSavaJ
       path.node.name = name
         .split("")
         .reverse()
         .join("");
     },
   },
 };
}

Presets

Don’t want to set up the plugin yourself? no problem! Presets can operate even shareable options configurations like a set of Babel plugins .

Official Presets

We have assembled some presets for common environments:

  • @babel/preset-env
  • @babel/preset-flow
  • @babel/preset-react
  • @babel/preset-typescript

There are many other community-maintained presets available on npm !

Stage-X (Experimental Presets)

Any conversion in stage-x presets is a change to a section that is not approved for publishing as Javascript (such as ES6 / ES2015).

Adjustable change

These proposals are subject to change, so please use them with caution , especially for proposals prior to Phase 3. We plan to update the changes to stage-x presets as soon as possible after each TC39 meeting.

TC39 divides the proposal into the following phases:

  • Stage 0 – Scarecrow: Just an idea might have a related Babel plugin.
  • Stage 1 – Proposal: Worth deep.
  • Stage 2 – Draft: Initial specification.
  • Stage 3 – Candidate: Complete specification and initial browser implementation.
  • Stage 4 – End: will be added to the next annual version.

For more information, be sure to check out the latest TC39 proposal and its process documentation .

Yehuda Katz (@wycatz) explains the TC39 phase process in several articles in thefeedbackloop.xyz : Stage 0 and 1 , Stage 2 , Stage 3 .

Create Preset

You only need to export a configuration to create your own preset.

It just returns an array of plugins just…

module.exports = function() {
 return {
   plugins: [
     "pluginA",
     "pluginB",
     "pluginC",
   ]
 };
}

Presets can contain other presets and plugins with options.

 module.exports = () => ({
 presets: [
   require("@babel/preset-env"),
 ],
 plugins: [
   [require("@babel/plugin-proposal-class-properties"), { loose: true }],
   require("@babel/plugin-proposal-object-rest-spread"),
 ],
});

See the babel handbook section for more information .

Preset path

If the preset on npm, you can pass the default name, babel will check if it has been installed node_modulesin

{
 "presets": ["babel-preset-myPreset"]
}

You can also specify the relative/absolute path of presets.

{
 "presets": ["./myProject/myPreset"]
}

Preset shorthand

If the name of the package to babel-preset-as a prefix, you can use the shorthand:

{
 "presets": [
   "myPreset",
   "babel-preset-myPreset" // Equivalent
 ]
}

This also applies to the scoped package:

 {
 "presets": [
   "@org/babel-preset-name",
   "@org/name" // Equivalent
 ]
}

Preset order

The order of Preset is the opposite (from the last to the first).

 {
 "presets": [
   "a",
   "b",
   "c"
 ]
}

Will run in the following order: c, b, then a.

This is mainly to ensure backward compatibility, as most users list “es2015” before “stage-0”.

Preset option

Both plugins and presets can specify options by placing name and option objects in an array in the configuration.

These are equivalent for not specifying options:

 {
 "presets": [
   "presetA",
   ["presetA"],
   ["presetA", {}],
 ]
}

To specify an option, pass the option name as the key pass object.

{
 "presets": [
   ["@babel/preset-env", {
     "loose": true,
     "modules": false
   }]
 ]
}

Babel Usage Options

  • Primary options
  • Config Loading options
  • Plugin and Preset configuration
  • Config Merging options
  • Source Map options
  • Misc options
  • Code Generator options
  • AMD / UMD / SystemJS options
  • Option concepts

Options can be passed to Babel in a variety of ways. When passed directly to Babel, you can just pass the objects object. When Babel is used via a wrapper, it may also be necessary, or at least more useful, to pass the options via configuration files.

If passing options via @babel/cli you’ll need to kebab-case the names. i.e.

npx babel --root-mode upward file.js # equivalent of passing the rootMode config option

Copy

Primary options

These options are only allowed as part of Babel’s programmatic options, so they are primarily for use by tools that wrap around Babel, or people calling babel.transform directly. Users of Babel’s integrations, like babel-loader or @babel/register are unlikely to use these.

cwd

Type: string

Default: process.cwd()

The working directory that all paths in the programmatic options will be resolved relative to.

caller

Type: Object with a string-typed “name” property.

Utilities may pass a caller object to identify themselves to Babel and pass capability-related flags for use by configs, presets and plugins. For example

 babel.transformFileSync("example.js", {
 caller: {
   name: "my-custom-tool",
   supportsStaticESM: true
 },
})

would allow plugins and presets to decide that, since ES modules are supported, they will skip compilation of ES modules into CommonJS modules.

filename

Type: string

The filename associated with the code currently being compiled, if there is one. The filename is optional, but not all of Babel’s functionality is available when the filename is unknown, because a subset of options rely on the filename for their functionality.

The three primary cases users could run into are:

  • The filename is exposed to plugins. Some plugins may require the presence of the filename.
  • Options like “test”, “exclude”, and “ignore” require the filename for string/RegExp matching.
  • .babelrc files are loaded relative to the file being compiled. If this option is omitted, Babel will behave as if babelrc: false has been set.

filenameRelative

Type: string

Default: path.relative(opts.cwd, opts.filename) (if “filename” was passed)

Used as the default value for Babel’s sourceFileName option, and used as part of generation of filenames for the AMD / UMD / SystemJS module transforms.

code

Type: boolean

Default: true

Babel’s default return value includes code and map properties with the resulting generated code. In some contexts where multiple calls to Babel are being made, it can be helpful to disable code generation and instead use ast: true to get the AST directly in order to avoid doing unnecessary work.

ast

Type: boolean

Default: false

Babel’s default is to generate a string and a sourcemap, but in some contexts it can be useful to get the AST itself. The primary use case for this would be a chain of multiple transform passes, along the lines of

const filename = "example.js";
const source = fs.readFileSync(filename, "utf8");

// Load and compile file normally, but skip code generation.
const { ast } = babel.transformSync(source, { filename, ast: true, code: false });

// Minify the file in a second pass and generate the output code here.
const { code, map } = babel.transformFromAstSync(ast, source, {
 filename,
 presets: ["minify"],
 babelrc: false,
 configFile: false,
});

Note: This option is not on by default because the majority of users won’t need it and because we’d like to eventually add a caching layer to Babel. Having to cache the AST structure will take significantly more space.

Config Loading options

Loading configuration can get a little complex as environments can have several types of configuration files, and those configuration files can have various nested configuration objects that apply depending on the configuration.

root

Type: string

Default: opts.cwd

Placement: Only allowed in Babel’s programmatic options

The initial path that will be processed based on the “rootMode” to determine the conceptual root folder for the current Babel project. This is used in two primary cases:

  • The base directory when checking for the default “configFile” value
  • The default value for “babelrcRoots”.

rootMode

Type: “root” | “upward” | “upward-optional”

Default: “root”

Placement: Only allowed in Babel’s programmatic options

Version: ^7.1.0

This option, combined with the “root” value, defines how Babel chooses its project root. The different modes define different ways that Babel can process the “root” value to get the final project root.

  • “root” – Passes the “root” value through as unchanged.
  • “upward” – Walks upward from the “root” directory, looking for a directory containing a babel.config.js file, and throws an error if a babel.config.js is not found.
  • “upward-optional” – Walk upward from the “root” directory, looking for a directory containing a babel.config.js file, and falls back to “root” if a babel.config.js is not found.

“root” is the default mode because it avoids the risk that Babel will accidentally load a babel.config.js that is entirely outside of the current project folder. If you use “upward-optional”, be aware that it will walk up the directory structure all the way to the filesystem root, and it is always possible that someone will have a forgotten babel.config.js in their home directory, which could cause unexpected errors in your builds.

Users with monorepo project structures that run builds/tests on a per-package basis may well want to use “upward” since monorepos often have a babel.config.js in the project root. Running Babel in a monorepo subdirectory without “upward”, will cause Babel to skip loading any babel.config.js files in the project root, which can lead to unexpected errors and compilation failure.

envName

Type: string

Default: process.env.BABEL_ENV || process.env.NODE_ENV || “development”

Placement: Only allowed in Babel’s programmatic options

The current active environment used during configuration loading. This value is used as the key when resolving “env” configs, and is also available inside configuration functions, plugins, and presets, via the api.env() function.

configFile

Type: string | boolean

Default: path.resolve(opts.root, “babel.config.js”), if it exists, false otherwise

Placement: Only allowed in Babel’s programmatic options

Defaults to searching for a default babel.config.js file, but can be passed the path of any JS or JSON5 config file.

NOTE: This option does not affect loading of .babelrc files, so while it may be tempting to do configFile: “./foo/.babelrc”, it is not recommended. If the given .babelrc is loaded via the standard file-relative logic, you’ll end up loading the same config file twice, merging it with itself. If you are linking a specific config file, it is recommended to stick with a naming scheme that is independent of the “babelrc” name.

babelrc

Type: boolean

Default: true as long as the filename option has been specified

Placement: Allowed in Babel’s programmatic options, or inside of the loaded “configFile”. A programmatic option will override a config file one.

true will enable searching for configuration files relative to the “filename” provided to Babel.

A babelrc value passed in the programmatic options will override one set within a configuration file.

Note: .babelrc files are only loaded if the current “filename” is inside of a package that matches one of the “babelrcRoots” packages.

babelrcRoots

Type: boolean | MatchPattern | Array<MatchPattern>

Default: opts.root

Placement: Allowed in Babel’s programmatic options, or inside of the loaded config File. A programmatic option will override a config file one.

By default, Babel will only search for .babelrc files within the “root” package because otherwise Babel cannot know if a given .babelrc is meant to be loaded, or if it’s “plugins” and “presets”have even been installed, since the file being compiled could be inside node_modules, or have been symlinked into the project.

This option allows users to provide a list of other packages that should be considered “root” packages when considering whether to load .babelrc files.

For example, a monorepo setup that wishes to allow individual packages to have their own configs might want to do

 babelrcRoots: [
 // Keep the root as a root
 ".",

 // Also consider monorepo packages "root" and load their .babelrc files.
 "./packages/*"
]

Plugin and Preset options

plugins

Type: Array<PluginEntry | Plugin> (PluginEntry)

Default: []

An array of plugins to activate when processing this file. For more information on how individual entries interact, especially when used across multiple nested “env” and “overrides” configs, see merging.

Note: The option also allows Plugin instances from Babel itself, but using these directly is not recommended. If you need to create a persistent representation of a plugin or preset, you should use babel.createConfigItem().

presets

Type: Array<PresetEntry> (PresetEntry)

Default: []

An array of presets to activate when processing this file. For more information on how individual entries interact, especially when used across multiple nested “env” and “overrides” configs, see merging.

Note: The format of presets is identical to plugins, except for the fact that name normalization expects “preset-” instead of “plugin-“, and presets cannot be instances of Plugin.

passPerPreset

Type: boolean

Default: false

Status: Deprecated

Instructs Babel to run each of the presets in the presets array as an independent pass. This option tends to introduce a lot of confusion around the exact ordering of plugins, but can be useful if you absolutely need to run a set of operations as independent compilation passes.

Note: This option may be removed in future Babel versions as we add better support for defining ordering between plugins.

Config Merging options

extends

Type: string

Placement: Not allowed inside of presets

Configs may “extend” other configuration files. Config fields in the current config will be merged on top of the extended file’s configuration.

env

Type: { [envKey: string]: Options }

Placement: May not be nested inside of another env block.

Allows for entire nested configuration options that will only be enabled if the envKey matches the envName option.

Note: env[envKey] options will be merged on top of the options specified in the root object.

overrides

Type: Array<Options>

Placement: May not be nested inside of another overrides object, or within an env block.

Allows users to provide an array of options that will be merged into the current configuration one at a time. This feature is best used alongside the “test”/”include”/”exclude” options to provide conditions for which an override should apply. For example:

overrides: [{
 test: "./vendor/large.min.js",
 compact: true,
}],
Copy

could be used to enable the compact option for one specific file that is known to be large and minified, and tell Babel not to bother trying to print the file nicely.

test

Type: MatchPattern | Array<MatchPattern> (MatchPattern)

If all patterns fail to match, the current configuration object is considered inactive and is ignored during config processing. This option is most useful when used within an overrides option object, but it’s allowed anywhere.

Note: These toggles do not affect the programmatic and config-loading options in earlier sections, since they are taken into account long before the configuration that is prepared for merging.

include

Type: MatchPattern | Array<MatchPattern> (MatchPattern)

This option is a synonym for “test”.

exclude

Type: MatchPattern | Array<MatchPattern> (MatchPattern)

If any of patterns match, the current configuration object is considered inactive and is ignored during config processing. This option is most useful when used within an overrides option object, but it’s allowed anywhere.

Note: These toggles do not affect the programmatic and config-loading options in earlier sections, since they are taken into account long before the configuration that is prepared for merging.

ignore

Type: Array<MatchPattern> (MatchPattern)

Placement: Not allowed inside of presets

If any of the patterns match, Babel will immediately stop all processing of the current build. For example, a user may want to do something like

ignore: [
 "./lib",
]
Copy

to explicitly disable Babel compilation of files inside the lib directory.

Note: This option disables all Babel processing of a file. While that has its uses, it is also worth considering the “exclude” option as a less aggressive alternative.

only

Type: Array<MatchPattern> (MatchPattern)

Placement: Not allowed inside of presets

If all of the patterns fail to match, Babel will immediately stop all processing of the current build. For example, a user may want to do something like

 only: [
 "./src",
]

Copy

to explicitly enable Babel compilation of files inside the src directory while disabling everything else.

Note: This option disables all Babel processing of a file. While that has its uses, it is also worth considering the “test”/”include” options as a less aggressive alternative.

Source Map options

inputSourceMap

Type: boolean | SourceMap

Default: true

true will attempt to load an input sourcemap from the file itself, if it contains a //# sourceMappingURL=… comment. If no map is found, or the map fails to load and parse, it will be silently discarded.

If an object is provided, it will be treated as the source map object itself.

sourceMaps

Type: boolean | “inline” | “both”

Default: false

  • true to generate a sourcemap for the code and include it in the result object.
  • “inline” to generate a sourcemap and append it as a data URL to the end of the code, but not include it in the result object.
  • “both” is the same as inline, but will include the map in the result object.

@babel/cli overloads some of these to also affect how maps are written to disk:

  • true will write the map to a .map file on disk
  • “inline” will write the file directly, so it will have a data: containing the map
  • “both” will write the file with a data: URL and also a .map.

Note: These options are bit weird, so it may make the most sense to just use true and handle the rest in your own code, depending on your use case.

sourceMap

This is an synonym for sourceMaps. Using sourceMaps is recommended.

sourceFileName

Type: string

Default: path.basename(opts.filenameRelative) when available, or “unknown”

The name to use for the file inside the source map object.

sourceRoot

Type: string

The sourceRoot fields to set in the generated source map, if one is desired.

Misc options

sourceType

Type: “script” | “module” | “unambiguous”

Default: “module”

  • script” – Parse the file using the ECMAScript Script grammar. No import/export statements allowed, and files are not in strict mode.
  • module” – Parse the file using the ECMAScript Module grammar. Files are automatically strict, and import/export statements are allowed.
  • unambiguous” – Consider the file a “module” if import/export statements are present, or else consider it a “script”. unambiguous can be quite useful in contexts where the type is unknown, but it can lead to false matches because it’s perfectly valid to have a module file that does not use import/export statements

This option is important because the type of the current file affects both parsing of input files, and certain transforms that may wish to add import/require usage to the current file.

For instance, @babel/plugin-transform-runtime relies on the type of the current document to decide whether to insert an import declaration, or a require() call. @babel/preset-env also does the same for its “useBuiltIns” option. Since Babel defaults to treating files are ES modules, generally these plugins/presets will insert import statements. Setting the correct sourceType can be important because having the wrong type can lead to cases where Babel would insert import statements into files that are meant to be CommonJS files. This can be particularly important in projects where compilation of node_modules dependencies is being performed, because inserting an import statements can cause Webpack and other tooling to see a file as an ES module, breaking what would otherwise be a functional CommonJS file.

Note: This option will not affect parsing of .mjs files, as they are currently hard-coded to always parse as “module” files.

highlightCode

Type: boolean

Default: true

Highlight tokens in code snippets in Babel’s error messages to make them easier to read.

wrapPluginVisitorMethod

Type: (key: string, nodeType: string, fn: Function) => Function

Allows users to add a wrapper on each visitor in order to inspect the visitor process as Babel executes the plugins.

  • key is a simple opaque string that represents the plugin being executed.
  • nodeType is the type of AST node currently being visited.
  • fn is the visitor function itself.

Users can return a replacement function that should call the original function after performing whatever logging and analysis they wish to do.

parserOpts

Type: {}

An opaque object containing options to pass through to the parser being used.

generatorOpts

Type: {}

An opaque object containing options to pass through to the code generator being used.

Code Generator options

retainLines

Type: boolean

Default: false

Babel will make an effort to generate code such that items are printed on the same line that they were on in the original file. This option exists so that users who cannot use source maps can get vaguely useful error line numbers, but it is only a best-effort, and is not guaranteed in all cases with all plugins.

compact

Type: boolean | “auto”

Default: “auto”

“auto” will set the value by evaluating code.length > 500_000

All optional newlines and whitespace will be omitted when generating code in compact mode.

minified

Type: boolean

Default: false

Includes compact: true, omits block-end semicolons, omits () from new Foo() when possible, and may output shorter versions of literals.

auxiliaryCommentBefore

Type: string

Allows specifying a prefix comment to insert before pieces of code that were not present in the original file.

Note: The definition of what is and isn’t present in the original file can get a little ugly, so usage of this option is not recommended. If you need to annotate code somehow, it is better to do so using a Babel plugin.

auxiliaryCommentAfter

Type: string

Allows specifying a prefix comment to insert after pieces of code that were not present in the original file.

Note: The definition of what is and isn’t present in the original file can get a little ugly, so usage of this option is not recommended. If you need to annotate code somehow, it is better to do so using a Babel plugin.

comments

Type: boolean

Default: true

Provides a default comment state for shouldPrintComment if no function is given. See the default value of that option for more info.

shouldPrintComment

Type: (value: string) => boolean

Default without minified: (val) => opts.comments || /@license|@preserve/.test(val)

Default with minified: () => opts.comments

A function that can decide whether a given comment should be included in the output code from Babel.

AMD / UMD / SystemJS module options

moduleIds

Type: boolean

Default: !!opts.moduleId

Enables module ID generation.

moduleId

Type: string

A hard-coded ID to use for the module. Cannot be used alongside getModuleId.

getModuleId

Type: (name: string) => string

Given the babel-generated module name, return the name to use. Returning a falsy value will use the original name.

moduleRoot

Type: string

A root path to include on generated module names.

Options Concepts

MatchPattern

Type: string | RegExp | (filename: string | void, context: { callee: { name: string } | void, envName: string ) => boolean

Several Babel options perform tests against file paths. In general, these options support a common pattern approach where each pattern can be

  • string – A file path with simple support for * and ** as full slug matches. Any file or parent folder matching the pattern counts as a match. The path follows Node’s normal path logic, so on POSIX is must be /-separated, but on Windows both / and \ are supported.
  • RegExp – A regular expression to match against the normalized filename. On POSIX the path RegExp will run against a /-separated path, and on Windows it will be on a \-separated path.

Importantly, if either of these are used, Babel requires that the filename option be present, and will consider it an error otherwise.

  • (filename: string | void, context: { callee: { name: string } | void, envName: string }) => boolean is a general callback that should return a boolean to indicate whether it is a match or not. The function is passed the filename or undefined if one was not given to Babel. It is also passed the current envName and callee options that were specified by the top-level call to Babel.

Merging

Babel’s configuration merging is relatively straightforward. Options will overwrite existing options when they are present, and their value is not undefined, with a few special cases:

  • parserOpts objects are merged, rather than replaced, using the same logic as top-level options.
  • generatorOpts objects are merged, rather than replaced, using the same logic as top-level options.
  • plugins and presets are replaced based on the identity of the plugin/preset object/function itself combined with the name of the entry.

Plugin/Preset merging

As an example, consider a config with:

Plugin/Preset merging

As an example, consider a config with:

 plugins: [
 './other',
 ['./plug', { thing: true, field1: true }]
],
overrides: [{
 plugins: [
   ['./plug', { thing: false, field2: true }],
 ]
}]

The overrides item will be merged on top of the top-level plugins. Importantly, the plugins array as a whole doesn’t just replace the top-level one. The merging logic will see that “./plug” is the same plugin in both cases, and { thing: false, field2: true } will replace the original options, resulting in a config as

 plugins: [
 './other',
 ['./plug', { thing: false, field2: true }],
],

Since merging is based on identity + name, it is considered an error to use the same plugin with the same name twice in the same plugins/presets array. For example

 plugins: [
 './plug',
 './plug',
]

is considered an error, because it’s identical to plugins: [‘./plug’]. Additionally, evenplugins:

[
 ['./plug', {one: true}],
 ['./plug', {two: true}]
]

is considered an error, because the second one would just always replace the first one.

If you actually do want to instantiate two separate instances of a plugin, you must assign each one a name to disambiguate them. For example:

plugins: [
 ['./plug', {one: true}, "first-instance-name"],
 ['./plug', {two: true}, "second-instance-name"]
]

because each instance has been given a unique name and this a unique identity.

Plugin/Preset entries

PluginEntry / PresetEntry

Individual plugin/preset items can have several different structures:

  • EntryTarget – Individual plugin
  • [EntryTarget, EntryOptions] – Individual plugin w/ options
  • [EntryTarget, EntryOptions, string] – Individual plugin with options and name (see merging for more info on names)
  • ConfigItem – A plugin configuration item created by babel.createConfigItem().

The same EntryTarget may be used multiple times unless each one is given a different name, and doing so will result in a duplicate-plugin/preset error.

That can be a little hard to read, so as an example:

 plugins: [
 // EntryTarget
 '@babel/plugin-transform-classes',

 // [EntryTarget, EntryOptions]
 ['@babel/plugin-transform-arrow-functions', { spec: true }],

 // [EntryTarget, EntryOptions, string]
 ['@babel/plugin-transform-for-of', { loose: true }, "some-name"],

 // ConfigItem
 babel.createConfigItem(require("@babel/plugin-transform-spread")),
]

EntryTarget

Type: string | {} | Function

A plugin/preset target can come from a few different sources:

  • string – A require-style path or plugin/preset identifier. Identifiers will be passed through name normalization.
  • {} | Function – An actual plugin/preset object or function after it has been require()ed.

EntryOptions

Type: undefined | {} | false

Options are passed through to each plugin/preset when they are executed. undefined will be normalized to an empty object.

false indicates that an entry is entirely disabled. This can be useful in contexts where ordering is important, but a separate condition is needed to decide if something is enabled. For instance:

 plugins: [
 'one',
 ['two', false],
 'three',
],
overrides: [{
 test: "./src",
 plugins: [
   'two',
 ]
}]

would enable the two plugin for files in src, but two would still execute between one and three.

Name Normalization

By default, Babel expects plugins to have a babel-plugin- or babel-preset- prefix in their name. To avoid repetition, Babel has a name normalization phase will automatically add these prefixes when loading items. This boils down to a few primary rules:

  • Absolute paths pass through untouched.
  • Relative paths starting with ./ pass through untouched.
  • References to files within a package are untouched.
  • Any identifier prefixed with module: will have the prefix removed but otherwise be untouched.
  • plugin-/preset- will be injected at the start of any @babel-scoped package that doesn’t have it as a prefix.
  • babel-plugin-/babel-preset- will be injected as a prefix any unscoped package that doesn’t have it as a prefix.
  • babel-plugin-/babel-preset- will be injected as a prefix any @-scoped package that doesn’t have it anywhere in their name.
  • babel-plugin/babel-preset will be injected as the package name if only the @-scope name is given.

Here are some examples, when applied in a plugin context:

Input Normalized
“/dir/plugin.js”
“/dir/plugin.js”
“./dir/plugin.js”“./dir/plugin.js”
“mod”“babel-plugin-mod”
“mod/plugin”“mod/plugin”
“babel-plugin-mod”“babel-plugin-mod”
“@babel/mod”“@babel/plugin-mod”
@babel/plugin-mod”“@babel/plugin-mod”
“@babel/mod/plugin”“@babel/mod/plugin”
“@scope”“@scope/babel-plugin”
“@scope/babel-plugin”“@scope/babel-plugin”
“@scope/mod”“@scope/babel-plugin-mod”
“@scope/babel-plugin-mod”“@scope/babel-plugin-mod”
“@scope/prefix-babel-plugin-mod”“@scope/prefix-babel-plugin-mod”
“@scope/mod/plugin”“@scope/mod/plugin”
“module:foo”“foo”

Related JavaScript Tutorials For Beginners

JavaScript Introduction Tutorials
Introduction to JavaScript
Javascript Code editors
Javascript Reference and Specifications
Javascript Developer Console
Javascript Basics
JavaScript Hello World.!
External JavaScript Files
JavaScript Code Structure
Use Strict in JavaScript
JavaScript Variables

Rollup Tutorial For Beginners 2019

Rollup Overview

Rollup Tutorial from Coding compiler. Rollup is a JavaScript module wrapper that compiles small pieces of code into large chunks of complex code, such as a library or application. Rollup uses a new standardized format for code modules, which are included in the ES6 version of JavaScript, rather than previous special solutions such as CommonJS and AMD.

The ES6 module gives you the freedom and seamless use of the most useful stand-alone functions in your favorite library, and your project doesn’t have to carry other unused code. The ES6 module will eventually be natively implemented by the browser, but current Rollup can give you an early experience.

Rollup Quick Start Guide

Use npm install –global rollup the installation. Rollup can be invoked via the command line interface with an optional configuration file, or it can be called via the JavaScript API . Run rollup –help can view the available options and parameters.

See the sample class libraries and application projects that use Rollup in rollup-starter-lib and rollup-starter-app .

These commands assume that the name of the application entry start is main.js, and that you want all import dependencies (all imports) to be compiled into a single file called bundle.js.

For the browser:

# compile to a <script> containing a self-executing function ('iife')
$ rollup main.js --o bundle.js --f iife

For Node.js:

# compile to a CommonJS module ('cjs')
$ rollup main.js --o bundle.js --f cjs

For browsers and Node.js:

# UMD format requires a bundle name
$ rollup main.js --o bundle.js -f umd --name "myBundle"

Why Rollup?

If you split the project into small separate files, developing software is usually straightforward because it usually eliminates unforeseen interactions and significantly reduces the complexity of the problem you are trying to solve (complexity) Of the problem), and small projects ( not necessarily standard answers ) can be written succinctly at the beginning of the project . Unfortunately, JavaScript has not used this feature as a core feature of the language.

Tree-shaking

In addition to using the ES6 module, Rollup also statically analyzes the import in the code and will exclude any code that is not actually used. This allows you to architect your existing tools and modules without adding extra dependencies or bloating your project.

For example, when using CommonJS, you must import the complete tool or library object .

// Import a full utils object using CommonJS
var utils = require( 'utils' );
var query = 'Rollup';
// Use the ajax method of the utils object
utils.ajax( 'https://api.example.com?search=' + query ).then( handleResponse );

However, the use ES6 module, without having to import the entire utils object, we can only import (import) we need ajax a function:

// Import ajax function using the ES6 import statement
import { ajax } from 'utils';
var query = 'Rollup';
// Calling ajax function
ajax( 'https://api.example.com?search=' + query ).then( handleResponse );

Because Rollup only introduces the most basic and streamlined code, it can generate lightweight, fast, and low-complexity libraries and applications. Because this based on explicit import and export fashion statements, it is far “in output in the compiled code, simply run variable automatic detection minifier unused” more effective.

Rollup Compatibility

Import CommonJS

Rollup can import existing CommonJS modules through plugins .

Publish ES6 Modules

To make sure your ES6 module directly with the “run (such as Node.js and webpack) of the tool (tool) in CommonJS” use, you can use the Rollup compiled into CommonJS or UMD format, and then in package.json the file main points to the current compilation properties version of. If you package.json have a module field like Rollup and webpack 2 such ES6 awareness tools (ES6-aware tools) will directly import ES6 module version .

Common Problems

Why are ES modules better than CommonJS modules?

The ES module is the official standard and a clear development direction for the JavaScript language, and the CommonJS module is a special traditional format that is a temporary solution before the ES module is proposed.The ES module allows for static analysis to achieve optimizations like tree-shaking and provides advanced features such as circular references and dynamic binding.

What is ‘tree-shaking’?

Tree-shaking, also known as “live code inclusion,” is a process of clearing code that is not actually used in a given project, but it can be more efficient. Glossary source view: similar to clearing useless code

How do I use Rollup in a CommonJS module? (How do I use Rollup in Node.js with CommonJS modules?)

Rollup strives to implement the specification of the ES module, not necessarily require()the features of Node.js, npm, , and CommonJS. Therefore, loading the CommonJS module and using the Node module location resolution logic are implemented as optional plugins, which are not by default in the Rollup kernel. You only need to perform npm install the installation CommonJS and node-resolve plug-in and use the rollup.config.js configuration file to enable them, then you’re all set.

Is Rollup used to build libraries or applications? (Is Rollup meant for building libraries or applications?)

Rollup has been used by many major JavaScript libraries and can be used to build most applications. However, Rollup does not support some specific advanced features, especially when building some applications, especially the dynamic import of runtimes for code splitting and runtime . If you need these features more in your project, then Using Webpack may be more in line with your needs.

Who made the Rollup logo. It’s so cute! (Who made the Rollup logo? It’s lovely.)

I know! It was made by Julian Lloyd .
null

Rollup Tutorial

Create the first bundle

Before you start, you need to install Node.js so that you can use npm ; you also need to know how to use command line .

The easiest way to use Rollup is through the Command Line Interface (or CLI). Install Rollup globally first (you’ll see how to install it in your project, it’s easier to package, but don’t worry about it now). Enter the following on the command line:

npm install rollup –global # or `npm i rollup -g` for short

Now you can run rollup commands. Try it~

rollup

Since no parameters were passed, Rollup printed out instructions for use. This is run rollup –help or rollup -h the same effect.

Let’s create a simple project:

mkdir -p my-rollup-project/src
cd my-rollup-project

First, we need an entrance . Paste the following code to the new file src/main.js in:

// src/main.js
import foo from './foo.js';
export default function () {
 console.log(foo);
}

After you create an entry file referenced foo.js modules:

// src/foo.js
export default 'hello world!';

Now you can create a bundle:

rollup src/main.js -f cjs

-fThe option ( –output.format short for) specifies the type of bundle created – here is CommonJS (running in Node.js). Since no output file is specified, it will be directly printed stdout in:’use strict’;

var foo = 'hello world!';

var main = function () {
 console.log(foo);
};

module.exports = main;

You can also save the bundle as a file as follows:

rollup src/main.js -o bundle.js -f cjs

(You can also use it rollup src/main.js -f cjs > bundle.js, but as we will see later, this method is not very flexible when generating sourcemaps.)

Try running the following code:

node
> var myBundle = require('./bundle.js');
> myBundle();
'hello world!'

Congratulations, you have completed the first bundle with Rollup.

Using configuration files (Using config files)

The above method is not bad, but if you add more options, this way of command line is cumbersome.

To do this, we can create a configuration file to include the required options. The configuration file is written in JavaScript and is more flexible than the CLI.

Create a project named in rollup.config.js the file, add the following code:

// rollup.config.js
export default {
 input: 'src/main.js',
 output: {
   file: 'bundle.js',
   format: 'cjs'
 }
};

We use –config or -c to use the configuration file:

rm bundle.js # so we can check the command works!
rollup -c

The same command line options will override the options in the configuration file:

rollup -c -o bundle-2.js # `-o` is short for `--output.file`

(Note Rollup itself will deal with configuration files, you can use export default the syntax – the code will not compile similar tool through Babel and so on, we can only use the ES2015 Node.js version supports syntax used.)

If you prefer, you can also specify the default rollup.config.js file different profiles:rollup –config rollup.config.dev.js
rollup –config rollup.config.prod.js

Use plugins (Using plugins)

So far, we have created a simple file and a module into a simple bundle through a relative path. As you build more complex bundles, you often need more flexibility—introducing npm-installed modules, compiling code through Babel, working with JSON files, and more.

To this end, we can use plug-ins (plugins) to change the behavior of the key processes Rollup packaged in. The Rollup wiki maintains a list of available plugins.

In this tutorial, we will use rollup-plugin-json to have Rollup read data from a JSON file.

Install rollup-plugin-json as a development dependency:

npm install --save-dev rollup-plugin-json

(We use –save-devinstead –save, because they do not rely on this plugin when the code is actually executed – except when packaging)

Update src/main.js file, rather than from package.json src/foo.js read data:

// src/main.js
import { version } from '../package.json';

export default function () {
 console.log('version ' + version);
}

Edit rollup.config.js the file, adding JSON plug-ins:

// rollup.config.js
import json from 'rollup-plugin-json';

export default {
 input: 'src/main.js',
 output: {
   file: 'bundle.js',
   format: 'cjs'
 },
 plugins: [ json() ]
};
npm run build Execute Rollup. The results are as follows:
'use strict';

var version = "1.0.0";

var main = function () {
 console.log('version ' + version);
};

module.exports = main;

(Note that only the data that we actually need and dev Dependencies –name and other data package.json is ignored. This is a tree-shaking played a role.)

Command Line

We generally use Rollup on the command line. You can also provide a configuration file (with or without) to simplify command line operations while also enabling advanced features of Rollup.

Configuration files

Rollup’s configuration file is optional, but the use of configuration files is very powerful and convenient, so we recommend that you use

The configuration file is an ES6 module that exposes an object externally. This object contains some options that Rollup needs. Usually, we call this configuration file rollup.config.js, which is usually located in the root of the project.

Take a close look at this list of options for a large number of options , you can configure it to your profile as you need it.

// rollup.config.js
export default {
 // Core option
 input,    
 external,
 plugins,

 // Extra options
 onwarn,

 // danger zone
 acorn,
 context,
 moduleContext,
 legacy

 output: {  // Must (if you want to output more than one, can be an array)
   // Core option
   file,    
   format,
   name,
   globals,

   // Extra options
   paths,
   banner,
   footer,
   intro,
   outro,
   sourcemap,
   sourcemapFile,
   interop,

   // High risk option
   exports,
   amd,
   indent
   strict
 },
};

You must use a configuration file to do the following:

If you want to use the Rollup configuration file, remember to add –config or -c @@2 to the command line.

Command line flags

Many of the options in the configuration file are equivalent to the parameters of the command line. If you use the parameters here, the configuration file will be overwritten. For more information, check out the list of options for this package.

-i, --input                 The file to be packaged (required)
-o, --output.file           Output file (if there is no such parameter, it will be output directly to the console)
-f, --output.format [es]    Output file type (amd, cjs, es, iife, umd)
-e, --external              Exclude a comma-separated list of module IDs
-g, --globals               In the form of the `module ID:Global` key-value pair, separated by commas
                              Any definition of module ID definition added to external dependencies here

-n, --name                  Generate the name of the UMD module
-m, --sourcemap            Generation sourcemap (`-m inline` for inline map)
--amd.id                    The ID of the AMD module, the default is an anonymous function
--amd.define                Use Function instead of `define`
--no-strict                 Omitted in the generated package "use strict";`
--no-conflict               For UMD modules, generate a collision-free method for global variables
--intro                     Insert a piece of content at the very top of the inside of the block of the packaged file (inside the wrapper)
--outro                     Insert a piece of content at the bottom of the inside of the block of the packaged file (inside the wrapper)
--banner                    Insert a piece of content at the very top of the outside of the block of the packaged file (wrapper outside)
--footer                    Insert a piece of content at the very bottom of the outside of the block of the packaged file (wrapper outside)
--interop                   Contains public modules (this option is added by default)

In addition, the following parameters are also available:

-h/--help

Print a help document.

-v/--version

Print the installed Rollup version number.

-w/--watch

Monitor the source file for changes, if there are changes, repackage

--silent

Do not print warnings to the console.

JavaScript API

Rollup provides a JavaScript interface that can be used with Node.js. You can use it very rarely, and you’re likely to use the command line interface unless you want to extend the Rollup itself, or for some obscure tasks, such as generating a bundle of files with code.

Rollup.rollup

The rollup.rollup function returns a Promise, it resolves an bundle object, which has different properties and methods, as follows:

const rollup = require('rollup');

// see below for details on the options
const inputOptions = {...};
const outputOptions = {...};

async function build() {
 // create a bundle
 const bundle = await rollup.rollup(inputOptions);

 console.log(bundle.imports); // an array of external dependencies
 console.log(bundle.exports); // an array of names exported by the entry point
 console.log(bundle.modules); // an array of module objects

 // generate code and a sourcemap
 const { code, map } = await bundle.generate(outputOptions);

 // or write the bundle to disk
 await bundle.write(outputOptions);
}

build();

Input parameters (inputOptions)

inputOptions The object contains the following properties:

const inputOptions = {
 // Core parameter
 input, // Only required parameter
 external,
 plugins,

 // Advanced parameters
 onwarn,
 cache,

 // Risk parameter
 acorn,
 context,
 moduleContext,
 legacy
};

Output parameters (outputOptions)

outputOptions Objects include the following properties:

const outputOptions = {
 // Core parameter
 file,   // bundle.write is required
 format, // Required
 name,
 globals,

 // Advanced parameters
 paths,
 banner,
 footer,
 intro,
 outro,
 sourcemap,
 sourcemapFile,
 interop,

 // danger zone
 exports,
 amd,
 indent
 strict
};

Rollup.watch

Rollup also provides a rollup.watch function, when it detects a single disk module has been changed, it will rebuild your files beam. When you run the Rollup from the command line, and bring the –watchmark, this function will be used internally.

const rollup = require('rollup');

const watchOptions = {...};
const watcher = rollup.watch(watchOptions);

watcher.on('event', event => {
 // event.code Will be one of the following:
 //   START        — The listener is starting (restart)
 //   BUNDLE_START — Build a single file bundle
 //   BUNDLE_END   — Complete file bundle construction
 //   END        — Complete all file bundle builds
 //   ERROR        — Encountered an error while building
 //   FATAL        — Encountered an unrecoverable error
});

// Stop listening
watcher.close();

Listening parameters (watchOptions)

watchOptions The parameter is a configuration (or a configuration data) that you will export from a configuration file.

const watchOptions = {
 ...inputOptions,
 output: [outputOptions],
 watch: {
   chokidar,
   include,
   exclude
 }
};

View more documents to know more inputOptions and outputOptions details or query big list of options off chokidar, include and exclude data.

Rollup integrates with other tools

Npm packages

At some point, your project is likely to rely on node_modules packages installed from npm into your folder. Unlike other bundles like Webpack and Browserify, Rollup doesn’t know how to break the rules to handle these dependencies. – We need to add some configuration.

Let’s add a simple dependency on the answer , which outputs answers to life, the universe, and everything else.

npm install the-answer # or npm i the-answer

If we modify the src/main.js entrance file …

// src/main.js
import answer from 'the-answer';

export default function () {
 console.log('the answer is ' + answer);
}

…and then execute Rollup…

npm run build

…we will see the following warnings:

 (!) Unresolved dependencies
https://github.com/rollup/rollup/wiki/Troubleshooting#treating-module-as-external-dependency
the-answer (imported by main.js)

After the package bundle.js will still work in Node.js, as import declared transformed into CommonJS in the require statement, but the-answer it is not included in the package. Therefore, we need a plugin.

Rollup-plugin-node-resolve

This rollup-plugin-node-resolve plugin tells Rollup how to find external modules. Install it…

npm install --save-dev rollup-plugin-node-resolve

…add it to your profile:

// rollup.config.js
import resolve from 'rollup-plugin-node-resolve';

export default {
 input: 'src/main.js',
 output: {
   file: 'bundle.js',
   format: 'cjs'
 },
 plugins: [ resolve() ]
};

This time, when you run npm run build, there is no warning output – the package file bundle contains the referenced module.

Rollup-plugin-commonjs

Some libraries are exported to ES6 modules the-answer that you can import normally – just one such module.But for now, most of the packages in npm come in the form of CommonJS modules. Before they change, we need to convert the CommonJS module to ES2015 for Rollup processing.

This rollup-plugin-commonjs plugin is used to convert CommonJS to ES2015 modules.

Please note that rollup-plugin-commonjs should be used in other plug-ins to convert your module before – this is to prevent the destruction of other plug-ins CommonJS change detection.

Peer dependencies

Suppose you are building a library with peer dependencies, such as React or Lodash. If you set up external references as described above, your Rollup will package all the modules of imports together:

import answer from 'the-answer';
import _ from 'lodash';

You can fine tune which imports are intended to be packaged and which are external references (externals). For this example, we think it lodash is an external reference (externals), not a the-answer.

This is the configuration file:

// rollup.config.js
import resolve from 'rollup-plugin-node-resolve';

export default {
 input: 'src/main.js',
 output: {
   file: 'bundle.js',
   format: 'cjs'
 },
 plugins: [resolve({
   // Pass custom options to the parsing plugin
   customResolveOptions: {
     moduleDirectory: 'node_modules'
   }
 })],
 // Indicate which modules should be considered as external modules
 external: ['lodash']
};

In this way, “lodash” will now be treated as external (externals) and will not be packaged with your library.

External Accepts an array of module names or a function that accepts the name of the module, or returns true if it is treated as an external reference (externals). E.g:

export default {
 // ...
 external: id => /lodash/.test(id)
}

If you use [babel-plugin-lodash] ( https://github.com/lodash/babel-plugin-lodash) to optimally choose the lodash module, in this case, Babel will convert your import statement as follows,

import _merge from 'lodash/merge';

The “external” array form does not handle wildcards, so this import will only be treated as external dependencies/externals in the form of functions.

Babel

Many developers use [Babel] ( https://babeljs.io/ ) in their projects so they can use future versions of JavaScript features that are not supported by browsers and Node.js.

The easiest way to use Babel and Rollup is to use [rollup-plugin-babel] ( https://github.com/rollup/rollup-plugin-babel). Install it:

npm i -D rollup-plugin-babel

Add to the Rollup configuration file rollup.config.js:

// rollup.config.js
import resolve from 'rollup-plugin-node-resolve';
import babel from 'rollup-plugin-babel';

export default {
 input: 'src/main.js',
 output: {
   file: 'bundle.js',
   format: 'cjs'
 },
 plugins: [
   resolve(),
   babel({
     exclude: 'node_modules/**' // Only compile our source code
   })
 ]
};

Configuration is required before Babel actually compiles the code. Create a new file src/.babelrc:

{
 "presets": [
   ["latest", {
     "es2015": {
       "modules": false
     }
   }]
 ],
 "plugins": ["external-helpers"]
}

This setting has some unusual places. First, we set “modules”: false it up , otherwise Babel will convert our module to CommonJS before Rollup has the opportunity to do it, causing some of Rollup’s processing to fail.

Second, we use external-helpers plugins, which allow Rollup to reference “helpers” only once at the top of the package, rather than referencing it once in each module that uses them (this is the default behavior).

Third, we put the .babelrc files in the src middle, not the root directory. This allows us to have different.babelrc configurations for different tasks , such as testing, if we need it later – usually it would be better to configure it separately for a separate task.

Now, before we run the rollup, we need to install the latest preset and the external-helpers plugin

npm i -D babel-preset-latest babel-plugin-external-helpers

Running Rollup will now create a bundle package… In fact we are not using any of the ES2015 features. Let’s change it. Edit src / main.js:

// src/main.js
import answer from 'the-answer';

export default () => {
 console.log(`the answer is ${answer}`);
}

Run Rollup npm run build and check the packaged bundle:

'use strict';

var index = 42;

var main = (function () {
 console.log('the answer is ' + index);
});

module.exports = main;

Gulp

Rollup returns promises that gulp can understand, so integration is easy.

The syntax is very similar to the configuration file, but the properties are divided into two different operations, corresponding to the JavaScript API :

const gulp = require('gulp');
const rollup = require('rollup');
const rollupTypescript = require('rollup-plugin-typescript');

gulp.task('build', async function () {
 const bundle = await rollup.rollup({
   input: './src/main.ts',
   plugins: [
     rollupTypescript()
   ]
 });

 await bundle.write({
   file: './dist/library.js',
   format: 'umd',
   name: 'library',
   sourcemap: true
 });
});

ES Module Syntax

The following is intended to be a lightweight reference to the module behavior defined in the ES2015 specification , as proper understanding of import and export statements is critical to the successful use of Rollup.

Import

Imported values ​​cannot be reassigned, although imported objects and arrays can be modified (export modules, and any other imports, will be affected by this modification). In this case, they behave like const statements.

Named Imports

Import a specific item whose original name is imported from the source module.

import { something } from './module.js';

Import a specific item from the source module and specify a custom name when importing.

import { something as somethingElse } from './module.js';

Namespace Imports

Imports everything in the source module as an object, exposing the naming export of all source modules as properties and methods. The default export is excluded from this object.

import * as module from './module.js'

The above example of “something” will be attached to the import object as an attribute. “module.something”.

Default Import

Import default export of source files

import something from './module.js';

Empty Import

Load the module code, but don’t create any new objects.

import './module.js';

This is useful for polyfills, or when the main purpose of the imported code is related to the prototype.

Export

Named exports

Export previously declared values:

var something = true;
export { something };

Rename when exporting:

export { something as somethingElse };

Export immediately after the statement:

// This can be `var`, `let`, `const`, `class`, and `function` With the use of
export var something = true;

Default Export

Export a value as the default export for the source module:

export default something;

This is recommended only if the source module has only one export.

It is not good practice to combine default and named exports in the same module, although it is allowed by the specification.

How binding works

The ES module exports real-time bindings instead of values, so the values ​​can be changed after the initial import based on this example :


// incrementer.js
export let count = 0;

export function increment() {
 count += 1;
}


// main.js
import { count, increment } from './incrementer.js';

console.log(count); // 0
increment();
console.log(count); // 1

count += 1; // Error — Only incrementer.js can change this value.

Large list of options

Core functionality

Input (input -i/--input )

String This entry point packet (e.g.: Your main.js or app.js or index.js)

File (file -o/–output.file )

String The file to be written. Can also be used to generate sourcemaps, if applicable

Format (format -f/–output.format )

String Generate the format of the package. One of the following:

  • amd – Asynchronous module definition for module loaders like RequireJS
  • cjs – CommonJS for Node and Browserify/Webpack
  • es – Save the package as an ES module file
  • iife– An auto-executing function suitable as a <script>label. (If you want to create a bundle for your application, you might want to use it because it will make the file size smaller.)
  • umd- universal module defined in amd, cjs and iife as a whole

Generate package name (name -n/–name )

String The variable name, which stands for your iife/ umd package, can be accessed by other scripts on the same page.


// rollup.config.js
export default {
 ...,
 output: {
   file: 'bundle.js',
   format: 'iife',
   name: 'MyBundle'
 }
};

// -> var MyBundle = (function () {...

Plugins

Plug-in object Array (or a Plug-in Object) – For more information, please refer to the plug-in entry .Remember to call the imported plugin function (ie commonjs(), instead of commonjs).

// rollup.config.js
import resolve from 'rollup-plugin-node-resolve';
import commonjs from 'rollup-plugin-commonjs';

export default {
 entry: 'main.js',
 plugins: [
   resolve(),
   commonjs()
 ]
};

External chain (external -e/–external )

Any two of a Function need for a idand returns true (external reference) or false (not external reference), or Array should be retained in the external bundle module ID references. The ID should be:

  1. Externally dependent name
  2. An ID of the path that has been found (like the absolute path of the file)
// rollup.config.js
import path from 'path';

export default {
 ...,
 external: [
   'some-externally-required-library',
   path.resolve( './src/some-local-file-that-should-not-be-bundled.js' )
 ]
};

When given as a command line argument, it should be a comma-separated list of IDs:

rollup -i src/main.js ... -e foo,bar,baz

Global module (globals -g/–globals )

Object In the form of id: name key-value pairs for umd/ iife package. For example: in such a case…

import $ from 'jquery';

… We want to tell Rollup jquery module id is equivalent to the $variable:

// rollup.config.js
export default {
 ...,
 format: 'iife',
 moduleName: 'MyBundle',
 globals: {
   jquery: '$'
 }
};

/*

var MyBundle = (function ($) {
 // Code here
}(window.jQuery));
*/

Alternatively, provide the ability to convert an external module ID to a global module.

When given as a command line argument, it should be a comma-separated list of “id:name” key-value pairs:

rollup -i src/main.js ... -g jquery:$,underscore:_

Advanced functionality

Path

Function, it gets an ID and returns a path, or id:path right Object. In the provided location, these paths will be used for the generated package instead of the module ID, allowing you to load dependencies, for example, from the CDN:

// app.js
import { selectAll } from 'd3';
selectAll('p').style('color', 'purple');
// ...

// rollup.config.js
export default {
 input: 'app.js',
 external: ['d3'],
 output: {
   file: 'bundle.js',
   format: 'amd',
   paths: {
     d3: 'https://d3js.org/d3.v4.min'
   }
 }
};

// bundle.js
define(['https://d3js.org/d3.v4.min'], function (d3) {

 d3.selectAll('p').style('color', 'purple');
 // ...

});

Banner/footer

String The string is prepended/appended to the bundle. (Note: the “banner” and “footer” options don’t break sourcemaps)

// rollup.config.js
export default {
 ...,
 banner: '/* my-library version ' + version + ' */',
 footer: '/* follow me on Twitter! @rich_harris */'
};

Intro/outro

String Similar banner and footer, in addition to the code inside any particular format wrapper.

export default {
 ...,
 intro: 'var ENVIRONMENT = "production";'
};

Cache

Object A previously generated package. Use it to speed up subsequent builds – Rollup will only reanalyze modules that have changed.

Onwarn

Function The warning message will be blocked. If not provided, the warning will be copied and printed to the console.

There is at least a warning code and message properties of objects, which means you can control how to handle different types of alerts:

onwarn (warning) {
 // Skip some warnings
 if (warning.code === 'UNUSED_EXTERNAL_IMPORT') return;

 // Throw an exception
 if (warning.code === 'NON_EXISTENT_EXPORT') throw new Error(warning.message);

 // Console prints everything warning
 console.warn(warning.message);
}

Many warnings also have a loc property and one frame that you can target to the source of the warning:

onwarn ({ loc, frame, message }) {
 // Print location (if applicable)
 if (loc) {
   console.warn(`${loc.file} (${loc.line}:${loc.column}) ${message}`);
   if (frame) console.warn(frame);
 } else {
   console.warn(message);
 }
}
Sourcemap -m/--sourcemap

If so true, a separate sourcemap file will be created. If so inline, the sourcemap will be appended to the generated output file as a data URI .

sourcemapFile

String The location of the generated package. If this is an absolute path, all source code paths in the sourcemap will be relative to it. map.fileThe attribute is sourcemapFile the base name (basename) because the location of the sourcemap is assumed to be adjacent to the bundle

If specified output, it sourcemapFile is not required, in which case the output file name will be inferred by adding a “.map” suffix to the bundle output file.

Interop

Boolean Whether to add ‘interop block’. By default ( interop:true), for security reasons, if you need to distinguish between default and named exports, Rollup will export any external dependencies “default” to a single variable. This usually only applies to your external dependencies (for example with Babel) (if you are sure you don’t need it), you can use “interop:false” to save a few bytes.

Danger zone

You may not need to use these options unless you know what you are doing!

Treeshake

Whether to apply tree-shaking. It is recommended that you omit this option (default is treeshake:true) unless you find a bug caused by the tree-shaking algorithm, in which case use “treeshake:false” once you have submitted the question!

Acorn

Any options that should be passed to Acorn, for example allowReserved:true.

Context

By default, the context of the module – this the value of the top level undefined. In rare cases, you may need to change it to something else, such as ‘window’.

moduleContext

And options.context the same, but each module may be id: context subject to, and may be a id => contextfunction.

Legacy

In order to increase support for legacy environments such as IE8, by stripping out more modern code that may not work properly, the cost is a departure from the precise specifications required for the ES6 module environment.

Exports

StringWhat export mode is used. By default auto, it entry guesses your intent based on what the module exports:

  • default- If you use export default …only export a thing, it is suitable to use this
  • named – If you export more than one thing, it is suitable to use this
  • none – If you don’t export anything (for example, you are building an application, not a library), then this is appropriate

Default And named the difference between affect how other people use the File bundle (bundle). If you use it default, CommonJS users can do this, for example

var yourLib = require( 'your-lib' );

Use named, the user can do this:

var yourMethod = require( 'your-lib' ).yourMethod;

A bit of a twist is if you use an named export, but there is also an default export, the user must do this to use the default export:

var yourMethod = require( 'your-lib' ).yourMethod;
var yourLib = require( 'your-lib' )['default'];

Amd –amd.idand–amd.define

Object Can contain the following attributes:

Amd.id is String used for the ID of the AMD/UMD package:

// rollup.config.js
export default {
 ...,
 format: 'amd',
 amd: {
   id: 'my-bundle'
 }
};

// -> define('my-bundle', ['dependency'], ...

Amd.define the String name of the function to use instead of define:

// rollup.config.js
export default {
 ...,
 format: 'amd',
 amd: {
   define: 'def'
 }
};

// -> def(['dependency'],...

Indent

String Is the indented string to use, for formats that need to be indented ( amd, iife, umd). Can also be false (no indentation) or true(default – auto indent)

// rollup.config.js
export default {
 ...,
 indent: false
};

Strict

True Or false (default true) – Whether to include ‘use strict’ pragma at the top of the generated non-ES6 package. Strictly speaking (geddit?), the ES6 module is always strictly mode, so you should have no good reason to disable it.

Watch options

Only use these options when you run the Rollup –watch signs or rollup.watch take effect.

Watch.chokidar

A Boolean value indicates you should use chokidar instead of the built-in fs.watchor a pass to the options object chokidar.

If you want to use it, you must install chokidar separately.

Watch.include

Limit file monitoring to certain files:

// rollup.config.js
export default {
 ...,
 watch: {
   include: 'src/**'
 }
}

Related JavaScript Tutorials For Beginners

JavaScript Introduction Tutorials
Introduction to JavaScript
Javascript Reference and Specifications
Javascript Developer Console
Javascript Code editors
JavaScript Basics Tutorial
JavaScript Hello World.!
JavaScript Code Structure
External JavaScript Files

Parcel Tutorial For Beginners 2019

Parcel Tutorial from Coding compiler. Parcel is a web application packaging tool for developers with different experiences. It utilizes multi-core processing to provide extremely fast speeds and does not require any configuration.

ParcelJs Tutorial – Getting Started with Parcel

First install Parcel via Yarn or npm:

Yarn:

yarn global add parcel-bundler

Npm:

npm install -g parcel-bundler

Create a package.json file in the project directory you are using:

yarn init -y

Or

npm init -y

Parcel can use any type of file as an entry, but it’s best to use an HTML or JavaScript file. If you introduce a main JavaScript file with a relative path in HTML, Parcel will also process it to replace it with the URL of the output file.

Next, create an index.html and index.js file.

 <html>
<body>
 <script src="./index.js"></script>
</body>
</html>
console.log("hello world");

Parcel has a built-in development server that automatically rebuilds the application when you change the file, and for rapid development, the development server supports hot module replacement . Just need to point out in the entry file:

parcel index.html

Now open http://localhost:1234/ in your browser . You can also use the -p <port number>option to override the default port. If you don’t have your own server, you can use the development server, or your application is completely rendered by the client. If you have your own server, you can watchrun Parcel in mode. It will still automatically rebuild and support hot swap when the file changes, but will not launch the web service.

parcel watch index.html

When you are ready to create in production mode, the build mode will turn off listening and only once. Please check the Production for more details.

Parcel Resources (Assets)

Parcel is resource-based, resources can represent arbitrary files, and Parcel has more support for JavaScript, CSS, and HTML files. Parcel automatically analyzes the dependencies referenced in these files and packages. Resources of the same type are combined into the same bundle. If you import other types of resources (for example, if you import a CSS file in a JS file), Parcel will launch the sub-bundle and keep a reference to it in the parent bundle. This will be explained in the following sections.

JavaScript

JavaScript is the most traditional type of web packaged file. Parcel supports both CommonJS and ES6 module syntax to import files. It also supports dynamic import()function syntax asynchronous loading module, it will be in the code split is discussed section.

// Import modules using CommonJS syntax
const dep = require('./path/to/dep');

// Import modules using ES6 syntax
import dep from './path/to/dep';

image files. When importing such files, Parcel does not inline the file like any other packaging tool, but instead places all dependencies in another bundle (for example: a CSS file).

When using CSS Modules , this exported class will be placed in a JavaScript package. The other resource files will be exported as URLs to the output in the JavaScript package so that they can be referenced in your code.

// Introducing CSS files
import './test.css';

// Introducing CSS files containing CSS modules
import classNames from './test.css';

// Import images as URLs
import imageURL from './test.png';

If you want to replace the URL import file with an inline file to a JavaScript package, you can use the Node.js fs.readFileSync API. The URL must be statically analyzable, meaning that it cannot have any variables (except for __dirnameand __filename).

import fs from 'fs';

// Read content as a string
const string = fs.readFileSync(__dirname + '/test.txt', 'utf8');

// Read content as a Buffer
const buffer = fs.readFileSync(__dirname + '/test.png');

CSS

JavaScript files or HTML files can be imported CSS resources, and through @importgrammar references dependence, but also by url()the function introducing images, fonts, and so on. Other by @importimported files are inline CSS to CSS with a bag, and url()references to rewrite its output file name. All file names should be associated with the current CSS file.

/* Introduce other CSS files */
@import './other.css';

.test {
 /* Reference image file */
 background: url('./images/background.png');
}

In addition to the normal CSS, other CSS preprocessor languages ​​such as LESS, SASS, and Stylus are also supported, and the execution method is the same.

SCSS

SCSS need to compile node-sassthe module via npm install it:

npm install node-sass

Once installed node-sass, you can import SCSS files into your JavaScript files.

import './custom.scss'

SCSS file dependencies can use @importstatement.

HTML

HTML resources are provided to Parcel’s common entry files, but can also be referenced by JavaScript files, such as providing links to other pages. Extract and compile URLs for scripts, styles, media, and other HTML files as described above. References are overridden in HTML to link to the correct output file. All file names should be associated with the current HTML file.

<html>
<body>
 <!-- Introducing image files -->
 <img src="./images/header.png">

 <a href="./other.html">Link to other pages</a>

 <!-- Introducing a JavaScript bundle -->
 <script src="./index.js"></script>
</body>
</html>

Parcel Transformations

Many packaging tools require you to install and configure plugins to convert resources. Parcel supports many out-of-the-box converters and built-in compilers. You can use Babel to convert JavaScript, PostCSS to convert CSS, and PostHTML to convert HTML. Parcel automatically runs and converts when it finds a configuration file (for example, .babelrc , .postcssrc) in the module.

This can even be a third-party node_modulesrun: If the configuration file was posted as part of the package, then only the module automatically enable conversion. Since you only need to process the modules that need to be converted, you can quickly package them. This also means that you don’t need to manually configure the transformation to include and exclude certain files, and you don’t need to know how to build third-party code to use it in your application.

Babel

Babel is a popular JavaScript converter with a large plugin ecosystem. Babel works with Parcel in the same way that it is used alone or with other packaging tools.

Install presets and plugins in your application:

yarn add babel-preset-env

Next, create one .babelrc:

{
 "presets": ["env"]
}

PostCSS

PostCSS is a tool for converting CSS using plugins, such as autoprefixer , cssnext, and CSS Modules . You can create a configuration using one of these names to achieve the purpose of configuring PostCSS with Parcel: .postcssrc(JSON), .postcssrc.js, or postcss.config.js.

Install plugins in your application:

yarn add postcss-modules autoprefixer
Next, create a .postcssrc file:
{
 "modules": true,
 "plugins": {
   "autoprefixer": {
     "grid": true
   }
 }
}

Plugins in plugins the specified object as key, and use the value of an object definition options. If the plug is no option, just set it trueto.

You can .browserslistrc specify autoprefixer, cssnext and target browser other tools:

> 1%
last 2 versions

Use top modules key, CSS module enables a slightly different way. This is because Parcel needs special support for CSS modules because they also export an object that is included in the JavaScript package. Please note that you still need to install it in your project postcss-modules.

PostHTML

PostHTML is a tool for converting HTML through plugins. You can create a configuration using one of these names to achieve the purpose of configuring PostHTML with Parcel: .posthtmlrc (JSON) , posthtmlrc.js, or posthtml.config.js.

Install plugin in your application:

yarn add posthtml-img-autosize
Next, create one .posthtmlrc:
{
 "plugins": {
   "posthtml-img-autosize": {
     "root": "./images"
   }
 }
}

TypeScript

TypeScript is a superset of JavaScript types that can be compiled into plain JavaScript and also supports the features of modern ES2015+. Converting TypeScript requires no extra configuration and is ready to use right out of the box.

 <!-- index.html -->
<html>
<body>
 <script src="./index.ts"></script>
</body>
</html>
// index.ts
import message from "./message";
console.log(message);
// message.ts
export default "Hello, world";

Parcel Code Splitting

Parcel supports zero configuration code splitting and is out of the box. This allows you to split the application’s code into separate packages that can be loaded on demand, which means smaller initial package sizes and shorter load times. As the user needs to load the corresponding module in the application, Parcel will automatically be responsible for loading the sub-bundle on demand.

When the code is resolved by the use of dynamic import()function syntax proposal controlled, the proposal with the general import statement or require similar function, but returns a Promise object. This means that the module is loaded asynchronously.

The following example shows how to use dynamic import to load a subpage of an application on demand.

 // pages/about.js
export function render() {
 // Render page
}
import('./pages/about').then(function (page) {
 // Render page
 page.render();
});

Because import()returns a Promise, so you can also use the async / await syntax. However, before the browser can support it extensively, you may need to configure Babel to convert the syntax.

const page = await import('./pages/about');
// Render page
page.render();

Dynamic load Parcel may be delayed import, so you still need all the import()calls placed on top of the file, and before using the sub-bundles, they will not be loaded. The following example shows how to dynamically delay loading a subpage of an application.

 // Set the page name to the dynamically imported map.
// These pages will not be loaded until they are used.
const pages = {
 about: import('./pages/about'),
 blog: import('./pages/blog')
};

async function renderPage(page) {
 // Lazy loading request page.
 const page = await pages[page];
 return page.render();
}

Note: If you still want to use does not support the syntax async / await in the local browser, remember that your application needs to introduce babel-polyfill or introduce in your library babel-runtime+ babel-plugin-transform-runtime.

yarn add babel-polyfill
import "babel-polyfill";
import "./app";

Hot Module Overload (HMR)

Hot Module Reload (HMR) automatically updates the module optimization development experience in the browser at runtime without having to refresh the entire page. This means that the state of the application can be preserved when your code changes slightly. Parcel’s HMR implementation supports out-of-the-box JavaScript and CSS resources. HMR is automatically disabled when it is built in production mode.

When you save the file, Parcel recompiles the changed content and sends an update containing the new code to any running client. The new code will replace the old version of the code and re-evaluate with all parents (Translator’s Note: This sentence is a bit strange to translate, everyone has a better translation welcome PR).

You can module.hothook this procedure using the API, and writing this code will notify you when you process the module or when a new version comes in. A similar project, react-hot-loader, can help you with this process and get it out of the box with Parcel.There are two known methods: module.hot.accept and module.hot.dispose. You can call module.hot.accept and give a callback function that executes when the module or other dependencies are updated. The module.hot.dispose callback function is called when the module is about to be replaced .

if (module.hot) {
 module.hot.dispose(function () {
   // When the module is about to be replaced
 });

 module.hot.accept(function () {
   // When the module or one of its dependencies has just been updated
 });
}

Safe Write

Some text editors and IDEs have Secure write features that basically prevent data loss by getting a copy of the text and renaming it when it is saved.

This feature prevents automatic detection of file updates when using Hot Module Overload (HMR). To disable it Secure write, use the options provided below:

  • Sublime Text 3 Add atomic_save: “false” to your user settings.
  • IntelliJ Use search in the settings to find “safe write” and disable it.
  • Vim Add: set backupcopy=yes to your settings.
  • WebStorm Uncheck the “safe write” option in Preferences > Appearance & Behavior > System Settings.

Production Environment (Production)

When you need to bind an application, you can use the production mode of Parcel.

parcel build entry.js

This will turn off listening mode and hot module replacement, so it will only compile once. It also turns on the minifier to reduce the size of the output package file. The minifiers used by Parcel are JavaScript uglify-es , CSS cssnano and HTML htmlnano .

Start the production mode and also set the environment variables NODE_ENV=production. Large libraries like React, which only use development debugging, can be built smaller and faster by setting this environment variable to disable debugging.

Options

Set the output directory

Default: “dist”

 parcel build entry.js --out-dir build/output
or
parcel build entry.js -d build/output
root
- build
- - output
- - - entry.js

Set the public URL to serve

Default: –out-dir option

parcel build entry.js --public-url ./

Will output to:

<link rel="stylesheet" type="text/css" href="1a2b3c4d.css">
or
<script src="e5f6g7h8.js"></script>

Disable compression

Default: minification enabled

parcel build entry.js --no-minify

Disable file system caching

Default: cache enabled

parcel build entry.js --no-cache

How Does Parcel Work?

Parcel The resource converting trees into a bundle tree. Many other packaging tools are basically based on JavaScript resources, as well as resources in other formats attached to them. For example, inline a string into a JS file. Parcel is non-aware of file types, works with any type of resource as you would expect, and does not need to be configured. Parcel’s packaging process has three steps.

1. Build a resource tree

Parcel accepts a single entry resource as input and can be of any type: a JS file, HTML, CSS, images, and more. There are many different resource types defined in Parcel that know how to handle specific file types. Resources are parsed, resource dependencies are extracted, and resources are converted to the final compiled form. This process creates a resource tree.

2. Build a bundle tree

Once the resource tree is built, the resources are placed in the bundle tree. First, an entry will be created as a resource bundle, then the dynamic import()will be created as a sub-bundle, which led to the split of the code.

When different types of file resources are introduced, the sibling bundle is created. For example, if you introduce a CSS file in JavaScript, it will be placed in a sibling bundle corresponding to the JavaScript file.

If a resource is referenced by more than one bundle, it is promoted to the nearest public ancestor in the bundle tree so that the resource is not packaged multiple times.

3. Packing

After the bundle tree is built, each bundle is written by the packager to a file of a specific file type. The packagers know how to merge the code from each resource into the file that is ultimately loaded by the browser.

Resource Type

As resource document in the description, Parcel will be seen as the input file Resource (Asset). Resource type is seen as inherited from the base Asset subclass of the class, and implements the necessary interfaces to parse, analyze dependence, conversion and code generation.

Because Parcel processes resources in parallel in a multiprocessor core, the conversion behavior that resource types can implement is limited to those that can manipulate a single file in a single time. For those conversion behaviors that require multiple files to be manipulated, a custom Packager is required .

Resource interface

const {Asset} = require('parcel-bundler');

class MyAsset extends Asset {
 type = 'foo'; // Set the main output type

 parse(code) {
   // Parse the code into an AST tree
   return ast;
 }

 pretransform() {
   // Optional. Convert before collecting dependencies.
 }

 collectDependencies() {
   // Analytical dependence
   this.addDependency('my-dep');
 }

 transform() {
   // Optional. Convert after collecting dependencies.
 }

 generate() {
   // Generated to do the right thing. Multiple transitions can be returned if needed.
   // The result will be passed to the appropriate packagers to generate the final file bundle
   return {
     foo: 'my stuff here', // Main output
     js: 'some javascript' // This conversion can be placed in a JS file bundle if needed.
   };
 }
}

Registered Resource Type

You can use the addAssetType method to register your resource type packaging tools. It accepts a file extension and the path to the resource type module. It is a path, not an actual object, so that it can be passed to the worker process.

const Bundler = require('parcel-bundler');

let bundler = new Bundler('input.js');
bundler.addAssetType('.ext', require.resolve('./MyAsset'));

Packagers

In Parcel in a Packager plurality of Resource combined into a bundle in the finally generated. This process takes place in the main process and after all resources have been processed and the bundle tree has been created. The registration of the Packager is based on the output file type, and the resources used to generate this file type are sent to the packager to generate the resulting output file.

Packager Interface

const {Packager} = require('parcel-bundler');

class MyPackager extends Packager {
 async start() {
   // Optional, write file header content
   await this.dest.write(header);
 }

 async addAsset(asset) {
   // have to, Write resources to the makefile.
   await this.dest.write(asset.generated.foo);
 }

 async end() {
   // Optional, write the internal content of the file.
   await this.dest.end(trailer);
 }
}

Register a Packager

You can use the addPackager method to register a packager in the packaging tool. It accepts a file type and the path to the packager module for registration.

const Bundler = require('parcel-bundler');

let bundler = new Bundler('input.js');
bundler.addPackager('foo', require.resolve('./MyPackager'));

Parcel Plugin

Parcel uses a slightly different strategy than many other tools, and many common formats are included out of the box without the need to install or configure additional plugins. However, there are situations where you may want to extend the capabilities of Parcel in non-standard situations, and at that time, plugins are supported. Installed plugin based package.json dependencies are automatically detected and loaded.

When you add a new file format to Parcel, you should first consider how common it will be, and how standardized it will be. If it is generic and standard enough, the format should probably be added to the core of Parcel, not as a plug-in that users need to install. If you have other doubts, you can discuss it with GitHub .

Plugin API

The Parcel plugin is simple. They simply output several modules as a function, which is automatically called by Parcel when it is initialized. Function receives Bundleran object as input, you can do some configuration, such as the resource type registration and registration packager.

module.exports = function (bundler) {
 bundler.addAssetType('ext', require.resolve('./MyAsset'));
 bundler.addPackager('foo', require.resolve('./MyPackager'));
};

Please publish this package to npm, and the use of parcel-plugin-the prefix, so that it will automatically detect and load as mentioned later.

Using Plugins

Using plugins in Parcel is easier than ever. You do, but they are installed and saved to package.json the. Plug-in needs to parcel-plugin-be prefixed to be named. For example parcel-plugin-foo. Any package.json dependency with this prefix are listed, it is automatically loaded during initialization.

Related JavaScript Tutorials For Beginners

JavaScript Introduction Tutorials
Introduction to JavaScript
Javascript Reference and Specifications
Javascript Code editors
Javascript Developer Console
Javascript Basics
JavaScript Hello World.!
External JavaScript Files
JavaScript Code Structure
Use Strict in JavaScript
JavaScript Variables

Webpack Tutorial

Webpack Tutorial from Coding compiler. Webpack is a static module bundler for modern JavaScript applications.

Webpack Tutorial

When webpack processes an application, it internally creates a dependency graph that maps to each module the project needs and then generates all of those dependencies into one or more bundles .

From here you will learn more about JavaScript module and webpack module.

Starting with webpack 4.0.0, you don’t have to package a project by introducing a configuration file . However, webpack it is still highly configurable , and can well meet the demand.

Core Concepts of Webpack

Before you start, you need to understand its core concepts :

  • Entry
  • Output
  • Loader
  • Plugins

This webpack tutorial is intended to give a high-level overview of these concepts , as well as detailed and relevant use cases for specific concepts.

To better understand the ideas behind the module packaging tool and how the underlying principles work, check out these materials:

Webpack Entry Point

The entry point indicates which module webpack should use as the start of building its internal dependency graph , and webpack will find out which modules and libraries are dependent on the entry point (direct and indirect).

The default value is ./src/index.js, however, you can specify a different entry start point by configuring the entry attribute in the webpack configuration (or you can specify multiple entry start points as well).

Webpack.config.js
module.exports = {
 entry: './path/to/my/entry/file.js'

Webpack Export

The output attribute tells webpack where to output the bundles it creates , and how to name these files. The main output file defaults to ./dist/main.js the default output directory for other generated files ./dist.

You can specify a configuration in the outputfield, to configure these processes:

Webpack.config.js

const path = require('path');

module.exports = {
 entry: './path/to/my/entry/file.js',
 output: {
   path: path.resolve(__dirname, 'dist'),
   filename: 'my-first-webpack.bundle.js'

In the above example, we are through output.filename and output.path property, to tell the name of webpack bundle, and we want to bundle generate (emit) where. Maybe you want to know what the path module is imported at the top of the code. It is a Node.js core module for manipulating file paths.

Output Properties also more configurable features , in the output section to learn more about its concept.

Webpack Loader

As a self-contained feature out of the box, webpack itself only supports JavaScript. The loader enables the processing of those non webpack JavaScript files, and converts them to a valid first module , and then added to the dependency graph, which can be provided to the applications.

Note, loader can import import any type of module (such as .cssa file), which is webpack specific features, other possible packaged program or task execution is not supported. We think this language extension is necessary because it allows developers to create more accurate dependency graphs.

At a higher level, the loader has two characteristics in the webpack configuration :

  • test An attribute that identifies one or some files that should be converted by the corresponding loader.
  • use Attribute, which indicates which loader should be used when converting.
Webpack.config.jsconst path = require('path');
module.exports = {
 output: {
   filename: 'my-first-webpack.bundle.js'
 },
 module: {
   rules: [
     { test: /\.txt$/, use: 'raw-loader'
Webpack.config.jsconst path = require('path');
module.exports = {
 output: {
   filename: 'my-first-webpack.bundle.js'
 },
 module: {
   rules: [
     { test: /\.txt$/, use: 'raw-loader' }

In the above configuration, a single module to define the object rules attribute, which contains two attributes must be: test and use. This tells the webpack compiler (compiler) the following information:

“Hey, the webpack compiler, when you get the path to ‘.txt’ in the require()/ import statement, use the raw-loader conversion before you package it. ”

It is important to remember when, defined in the configuration loader in webpack, to be defined in module.rules instead rules. In order for you to benefit from this, webpack will give a warning if it is not done in the right way.

You can go deeper into the loader chapter to learn more about customizing the imported loader.

Webpack Plugins

The loader is used to convert certain types of modules, while the plug-ins can be used to perform a wider range of tasks, including: package optimization, resource management, and injection environment variables.

By looking at plug-in interface documentation to learn how to use it extend webpack function.

Wants to use a plug-in, you only need require()it, then add it to the plugins array. Most plugins can be customized with options. You can also use multiple times because of the different purposes with a plug in a configuration file, then need to use new to create an instance of operator.

Webpack.config.js
const HtmlWebpackPlugin = require('html-webpack-plugin'); // 通过 npm 安装
const webpack = require('webpack'); // 用于访问内置插件

module.exports = {
 module: {
   rules: [
     { test: /\.txt$/, use: 'raw-loader' }
   ]
 },
 plugins: [
   new HtmlWebpackPlugin({template: './src/index.html'})

In the above example, html-webpack-plugin an html file is generated for your application and then all generated bundles are automatically injected.

Webpack offers many plugins available out of the box! Check out our list of plugins for more information.

The use of plug-in webpack configuration is straightforward, but there are a lot we can further explore the use cases! .

Webpack mode

By mode parameter setting development, production or none, in a corresponding WebPACK built environment can enable optimization. The default is production.

module.exports = {
 mode: 'production'

From the mode configuration can learn what to do in each mode are optimized.

Webpack Browser Compatibility

Webpack supports all ES5 compatible browsers (IE8 and below are not supported). webpack of import() and require.ensure()need to have an environment Promise. Before if you want to support older browsers, you should use the expression of these webpack provided to load a polyfill.

Webpack Entry Points

As we mentioned at the starting, there are many ways defined in webpack configuration entry attributes. Explain why it can be very useful addition, we’ll also show you how to configure entry properties.

Single Entry Syntax

usage:entry: string|Array<string>
Webpack.config.js
module.exports = {
 entry: './path/to/my/entry/file.js'
};

entry The single entry syntax for an attribute is the following shorthand:

module.exports = {
 entry: {
   main: './path/to/my/entry/file.js'
 }
};

When you ask entry when passed an array of what would happen? To entry pass “file path (file path) array” attribute will create “more the main entrance (Multi-main entry)” . The way you pass in an array is useful when you want multiple dependency files to be injected together and graph their dependencies into a “chunk”.

This is a great choice when you are looking for a quick setup of the webpack configuration for an application or tool that has only one entry point (ie library). However, using this syntax is inflexible when extending the configuration.

Object Syntax

usage:entry: {[entryChunkName: string]: string|Array<string>}
Webpack.config.jsmodule.exports = {
 entry: {
   app: './src/app.js',
   vendors: './src/vendors.js'
 }
};

Object syntax can be cumbersome. However, this is the most scalable way to define entries in your application.

“Extensible webpack configuration” means reusable and can be combined with other configurations. This is a popular technique for separating concerns from the environment, build targets, and runtimes. Then merge them using specialized tools like webpack-merge .

Common use cases:

Here are some of the entry configurations and their actual use cases:

Separate application (app) and third party (vendor) portals

Webpack.config.js

module.exports = {
 entry: {
   app: './src/app.js',
   vendors: './src/vendors.js'
 }
};

what is this? On the surface, this tells us webpack from app.js and vendors.js start creating dependency graph (dependency graph). These dependency graphs are completely separate and independent of each other (one webpack bootstrap in each bundle). This approach is more common in a single page application with only one entry start (excluding the vendor).

why? This setting allows you CommonsChunkPlugin to extract vendor references (vendor reference) to the vendor bundle, and the partial replacement of references from the vendor for the “application bundle” the __webpack_require__() calls. If there is no vendor code in the application bundle, then you can implement a generic pattern called long- lived caching in webpack .

To support DllPlugin that provides better vendor separation, consider removing the scenario.

Multi-page application

Webpack.config.jsmodule.exports = {
 
entry: {
   pageOne: './src/pageOne/index.js',
   pageTwo: './src/pageTwo/index.js',
   pageThree: './src/pageThree/index.js'

what is this? We tell webpack that we need 3 separate dependency graphs (as in the example above).

why? In a multi-page application, the server will get a new HTML document for you. The page reloads the new document and the resource is re-downloaded. However, this gives us a special opportunity to do a lot of things:

Use CommonsChunkPlugin the application to share code between each page to create a bundle. Due to the increased number of entry points, multi-page applications can reuse a large number of code/modules between the entry points, which can greatly benefit from these technologies.

Based on experience: each HTML document uses only one entry start point.

Webpack Output

Configuration output options control webpack how to compile files written to the hard disk. Note that Entrance only one Output configuration can be specified , even though there can be multiple starting points .

Usage

Webpack arranged in the output minimum property requirement is to set its value to an object, comprising the following two points:

  • filename The name of the file to use for the output file.
  • Target output directory path absolute path.
webpack.config.js

module.exports = {
 output: {
   filename: 'bundle.js',
   path: '/home/proj/public/assets'
This configuration of a single bundle.js output file to the /home/proj/public/assets directory.

Multiple Entry Points

If the configuration creates multiple separate “chunks” (for example, using multiple entry starters or using plugins like CommonsChunkPlugin), you should use substitutions to ensure that each file has a unique name.

module.exports = {
 entry: {
   app: './src/app.js',
   search: './src/search.js'
 },
 output: {
   filename: '[name].js',
   path: __dirname + '/dist'
 }
};

// Write to hard disk:./dist/app.js, ./dist/search.js

Advanced Output

The following is a complex example of using CDN and resource hashes:

config.jsmodule.exports = {
 //...
 output: {
   path: '/home/proj/cdn/assets/[hash]',
   publicPath: 'http://cdn.example.com/assets/[hash]/'

Final output file does not know at compile time publicPath the path of the case, publicPath can be left blank, is provided at the inlet and the dynamic run file start point. If you don’t know at compile time publicPath, you can ignore it first and set it at the beginning of the entry __webpack_public_path__.

__webpack_public_path__ = myRuntimePublicPath;
// Remaining application portal

Webpack Mode

Provide mode configuration options, use the built-in optimization inform webpack corresponding mode.

string

Mode The default value is production.

Usage

Only in the configuration mode options

module.exports = {
 mode: 'production'
};

Or pass from the CLI parameters:

webpack --mode=production

The following string values ​​are supported:

Development:

It will process.env.NODE_ENVset the value development. Enabling NamedChunksPlugin and NamedModulesPlugin.

Production:It will process.env.NODE_ENVset the value production. Enable FlagDependencyUsagePlugin, FlagIncludedChunksPlugin,

ModuleConcatenationPlugin, NoEmitOnErrorsPlugin, OccurrenceOrderPlugin, SideEffectsFlagPluginand UglifyJsPlugin.

None: Do not use any default optimization options

If not set, webpack will be production used as mode default values to set. Among them, mode supports the following values:

Remember, just set NODE_ENVthe time, it does not automatically set mode.

mode: development

// webpack.development.config.js

module.exports = {
+ mode: 'development'
- plugins: [
-   new webpack.NamedModulesPlugin(),
-   new webpack.NamedChunksPlugin(),
-   new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("development") }),
- ]
}

mode: production

// webpack.production.config.js

module.exports = {
+  mode: 'production',
-  plugins: [
-    new UglifyJsPlugin(/* ... */),
-    new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("production") }),
-    new webpack.optimize.ModuleConcatenationPlugin(),
-    new webpack.NoEmitOnErrorsPlugin()
-  ]
}

mode: none

// webpack.custom.config.js

module.exports = {
+  mode: 'none',
-  plugins: [
-  ]
}

If you want to influence the compilation behavior based on the mode variable in webpack.config.js , you must export the object instead of exporting a function:

var config = {
 entry: './app.js'
 //...
};

module.exports = (env, argv) => {

 if (argv.mode === 'development') {
   config.devtool = 'source-map';
 }

 if (argv.mode === 'production') {
   //...
 }

 return config;
};

Webpack Loader

The loader is used to convert the source code of the module. loader can make you import or “load” file preprocessing module. Therefore, the loader is similar to the “task” in other build tools and provides a powerful way to handle front-end build steps. The loader can convert files from different languages ​​(such as TypeScript) to JavaScript, or convert inline images to data URLs. The loader even allows you to directly load import CSS files in a JavaScript module !

Webpack Loader Example

For example, you can use the loader to tell webpack to load CSS files, or to convert TypeScript to JavaScript. To do this, first install the corresponding loader:

npm install --save-dev css-loader
npm install --save-dev ts-loader

Then webpack instructions for each .css use css-loader, as well as for all .ts use of the file ts-loader:

Webpack.config.js

module.exports = {
 module: {
   rules: [
     { test: /\.css$/, use: 'css-loader' },
     { test: /\.ts$/, use: 'ts-loader' }
   ]
 }
};

Using Loader

There are three ways to use the loader in your application:

  • Configuration (recommended): Specify the loader in the webpack.config.js file.
  • Inline : each import explicitly specify loader statement.
  • CLI : Specify them in a shell command.

Configuration

Module.rules Allows you to specify multiple loaders in the webpack configuration. This is a concise way to show the loader and help to make the code simple. It also gives you a global overview of each loader:

module.exports = {
 module: {
   rules: [
     {
       test: /\.css$/,
       use: [
         { loader: 'style-loader' },
         {
           loader: 'css-loader',
           options: {
             modules: true
           }
         }
       ]
     }
   ]
 }
};

Inline

Can import statement or any equivalent to “import” a way to specify the loader. Use !separate resource loader. Each part that is separated is parsed relative to the current directory.

import Styles from 'style-loader!css-loader?modules!./styles.css';

By prepending all rules and usage !, the source file can be reloaded into any loader in the configuration.

Options can pass query parameters, for example ?key=value & foo=bar, or a JSON object, for example ?{“key”:”value”,”foo”:”bar”}.

Use module.rules it whenever possible , as this reduces the amount of code in the source code and allows you to debug and locate problems in the loader faster when errors occur.

CLI

You can also use the loader via the CLI:

webpack --module-bind jade-loader --module-bind 'css=style-loader!css-loader'

It will .jade document the use jade-loader of .css files style-loader and css-loader.

Loader Feature

  • The loader supports chained delivery. Each loader in the loader chain converts the resources processed by the previous loader. The loader chain will execute in the reverse order. The first loader passes the result of the application (using the converted resource) to the next loader, which is executed in turn. Finally, the last loader in the chain returns the JavaScript expected by webpack.
  • The loader can be synchronous or asynchronous.
  • The loader runs in Node.js and is able to perform any possible operations.
  • The loader receives the query parameters. Used to pass the configuration to the loader.
  • It can also be used loader options object configuration.
  • In addition to the use of package.json common main property can also be exported as plain npm module loader, practice is package.json defined in a loaderfield.
  • Plugins can bring more features to the loader.
  • The loader can generate additional arbitrary files.

The loader provides more power to the JavaScript ecosystem through the (loader) preprocessor. Users now have more flexibility in introducing fine-grained logic such as compression, packaging, language translation, and more .

Parsing loader

The loader follows standard module parsing . In most cases, loader from the module path (usually the module path considered npm install, node_modules) resolution.

The loader module needs to be exported as a function and written in Node.js compatible JavaScript. It is usually managed using npm, but you can also use a custom loader as a file in your application. By convention, the loader is usually named xxx-loader (for example json-loader).

Webpack Plugins

Plugins are the backbone of webpack . The webpack itself is built on top of the same plugin system you used in the webpack configuration !

The plugin is designed to solve other things that the loader can’t .

Anatomy

webpack plug-in is having a apply JavaScript object method. Apply The properties are called by the webpack compiler, and the compiler object is accessible throughout the compilation lifecycle.

ConsoleLogOnBuildWebpackPlugin.js
const pluginName = 'ConsoleLogOnBuildWebpackPlugin';

class ConsoleLogOnBuildWebpackPlugin {
 apply(compiler) {
   compiler.hooks.run.tap(pluginName, compilation => {
     console.log('webpack The build process begins!');
   });
 }
}

The first argument to the tap method of the compiler hook should be the name of the camel named plugin. It is recommended to use a constant for this so that it can be reused in all hooks.

Usage

Since the plug can carry parameters / options, you must webpack configuration, the pluginsincoming attribute newinstance.

There are several ways to use plugins depending on your webpack usage.

Configuration

webpack.config.js
const HtmlWebpackPlugin = require('html-webpack-plugin'); //Install via npm
const webpack = require('webpack'); //Access the built-in plugin
const path = require('path');

module.exports = {
 entry: './path/to/my/entry/file.js',
 output: {
   filename: 'my-first-webpack.bundle.js',
   path: path.resolve(__dirname, 'dist')
 },
 module: {
   rules: [
     {
       test: /\.(js|jsx)$/,
       use: 'babel-loader'
     }
   
]
 },
 plugins: [
   new HtmlWebpackPlugin({template: './src/index.html'})
 ]
};

API Node

Even with Node API, the user should be passed in the configuration plugins properties. Compiler.apply Not the recommended way to use it.

some-node-script.js
const webpack = require('webpack'); //Access webpack runtime
const configuration = require('./webpack.config.js');

let compiler = webpack(configuration);
compiler.apply(new webpack.ProgressPlugin());

compiler.run(function(err, stats) {
 // ...
});

Did you know that the example seen above is very similar to webpack’s own runtime (runtime) . There are a lot of usage examples hidden in the wepback source , which you can use in your own configuration and scripts.

Webpack Configuration

You may have noticed that very few webpack configurations look exactly the same. This is because the webpack configuration file is a JavaScript file that exports an object. This object is parsed by webpack based on the properties defined by the object.

Because the webpack configuration is a standard Node.js CommonJS module, you can do the following :

  • By require(…)import other files
  • By require(…)using npm utility functions
  • JavaScript expression using flow control, for example, ?:the operator
  • Use constants or variables for commonly used values
  • Write and execute functions to generate partial configurations

Please use these features at the right time.

Although technically feasible, the following practices should be avoided :

  • Access command line interface (CLI) parameters when using the webpack command line interface (CLI) (should write your own command line interface (CLI), or use–env )
  • Export undefined values ​​(calling webpack twice should produce the same output file)
  • Write a very long configuration (you should split the configuration into multiple files)

The biggest thing you need to get from this document is your webpack configuration, which can be in a variety of formats and styles. But for you and your team to be easy to understand and maintain, you should always adopt the same usage, format and style.

The following example shows how the webpack configuration object is both expressive and configurable because the configuration object is the code :

Basic Configuration

Webpack.config.js
var path = require('path');

module.exports = {
 mode: 'development',
 entry: './foo.js',
 output: {
   path: path.resolve(__dirname, 'dist'),
   filename: 'foo.bundle.js'
 }
};

Multiple Targets

View: Export multiple configurations

Use a different configuration language

Webpack accepts configuration files written in a variety of programming and data languages.

Webpack Modules

In modular programming , developers break down the program into discrete chunks of functionality and call it _module_.

Each module has a smaller contact surface than the full program, making verification, debugging, and testing a breeze. The well-written _module_ provides reliable abstraction and encapsulation boundaries, giving each module in the application a well-organized design and clear purpose.

Node.js supports modular programming from the very beginning. However, on the web, modular support is coming slowly. There are several tools on the web that support JavaScript modularity, each with its own advantages and limitations. The webpack is based on lessons learned from these systems and applies the concept of _module_ to any file in the project.

What is the webpack module?

Comparing the Node.js module , webpack_module_ can express their dependencies in various ways, a few examples are as follows:

Webpack 1 requires a specific loader to convert ES 2015 import, but webpack 2 can be used out of the box.

Supported module types

Webpack supports various languages ​​and preprocessor writing modules through the loader . loader described webpack how to deal with non-JavaScript (non-JavaScript) _ _ module, and a bundle introduction of these dependencies _ _. The webpack community has built loaders for a variety of popular language and language processors , including:

In general, webpack provides a customizable, powerful, and rich API that allows any technology stack to use webpack, keeping it non- opinionated in your development, testing, and build processes

Webpack Module Resolution

The resolver is a library that helps to find the absolute path of the module. A module can be used as a dependency module for another module and then referenced by the latter, as follows:

import foo from 'path/to/module';
// or
require('path/to/module');

The module that depends on can be a library from application code or a third party. The resolver helps webpack find the module code that needs to be introduced in the bundle, which is included in each require/ import statement. Webpack Use enhanced-resolve to parse file paths when packaging modules

Parsing rules in webpack

Using enhanced-resolve webpack, it can parse the three file paths:

Absolute path

import '/home/me/file';
import 'C:\\Users\\me\\file';

Since we have obtained the absolute path of the file, no further analysis is required.

Relative path

import ‘../src/file1’;
import ‘./file2’;

In this case, use import or require directory resource file (resource file) where the context is considered directory (context directory). In import/require a relative given path, the path will add this context (context path), to generate an absolute path to the module (absolute path).

Module path

import 'module';
import 'module/lib/file';

Module will resolve.modules search all directories specified. You can replace the original module path, through the use of this alternative path resolve.alias to create an alias configuration options.

Once the path is resolved according to the above rules, the resolver will check if the path points to a file or directory. If the path points to a file:

  • If the path has a file extension, the file is packaged directly.
  • Otherwise, the [ resolve.extensions] option is used as a file extension to resolve, which tells the parser which extensions (for example .js, .jsx) can be accepted in parsing .

If the path points to a folder, take the following steps to find the correct file with the correct extension:

  • If the folder contains package.json files, in order to find resolve.mainFields the configuration options specified in the field. And package.json the first such field determines the file path.
  • If the package.json file does not exist or package.json main field file does not return a valid path, in order to find resolve.mainFiles the configuration options specified in the file name, to see if there is a match to the file name in the import / require directory.
  • File extensions resolve.extensions parsing using a similar method options.

The webpack provides a reasonable default configuration for these options based on the build target .

Parsing Loader (Resolving Loaders)

Loader parsing follows the same rules as those specified by the file parser. But the resolveLoader configuration options can be used to provide independent parsing rules for the Loader.

Cache

Each file system access is cached to trigger multiple parallel or serial requests to the same file faster. In observation mode , only modified files are extracted from the cache. If you turn off watch mode, clean up the cache before each compilation.

Webpack Dependency Graph

At any time, one file depends on another, and webpack treats this as a dependency between files . This allows webpack to receive non-code assets (such as images or web fonts) and can provide them as _dependencies to your application.

Webpack starts with a list of modules defined in the command line or configuration file and processes your application. From the beginning of these entries , webpack recursively builds a dependency graph that contains each module required by the application and then packages all of these modules into a small number of bundles– usually only one – that can be loaded by the browser.

For HTTP/1.1 clients, packaging your application by webpack is especially powerful because it reduces the amount of time an application must wait when a new request is made by the browser. For HTTP/2 , you can also use Code Splitting and webpack packaging for optimal optimization

Webpack Manif

There are three main types of code in a typical application or site built using webpack:

  1. Source code written by you or your team.
  2. Your third source’s library or “vendor” code will depend on your source code.
  3. The webpack’s runtime and manifest manage the interaction of all modules.

This article will focus on the last of these three parts, runtime and manifest.

Runtime

As mentioned above, we will only briefly introduce it here. The runtime, along with the accompanying manifest data, mainly refers to all the code that webpack uses to connect to the modular application while the browser is running. The runtime contains: the loading and parsing logic required to connect the modules as they interact. Includes connections to loaded modules in the browser, and execution logic for lazy loading modules.

Manifest

Then, once your application, shaped like a index.html file, some of the bundle and resources loaded into the browser, what happens? You orchestrated /src the file directory structure does not exist now, so webpack how to manage the interaction between all the modules it? This is the origin of the use of manifest data…

When the compiler starts executing, parsing, and mapping the application, it retains the detailed points of all the modules. This collection of data is called “Manifest” and is parsed and loaded by Manifest at runtime when it is packaged and sent to the browser. Whichever you choose modules grammar , those import or require statements have now been converted to a __webpack_require__method, which points to the module identifier (module identifier). By using the data in the manifest, the runtime will be able to query the module identifier and retrieve the corresponding module behind it.

Problem

So now you should have a little understanding of webpack working behind the scenes. “But what does this have to do with me?”, you might ask. The answer is not in most cases. The runtime does what it does, uses the manifest to perform its operations, and once your application is loaded into the browser, everything will show magical operation. However, if you decide to improve the performance of your project by using browser caching, understanding this process will suddenly become even more important.

By using the bundle to calculate the content hash as the file name, when the content or file is modified, the browser will point to the new file through the new content hash, thus invalidating the cache. Once you start doing this, you will immediately notice some interesting behavior. Even if some of the content on the surface is not modified, the calculated hash will change. This is because the injection of runtime and manifest changes every time you build.

Webpack Build Targets

Because both the server and browser code can be written in JavaScript, webpack provides a variety of build targets that you can set in your webpack configuration .

webpack the target property and not to output.libraryTarget attribute

Usage

To set the targetproperty, only you need to set the value of the target in your webpack configuration.

Webpack.config.js
module.exports = {
 target: 'node'
};

In the above example, the use of node webpack will be compiled into a “class Node.js” environment (using the Node.js require, rather than using any of the built-in modules (such as fsor path) to load the chunk).

Each target has a variety of deployment/environment-specific add-ons to support its needs. Look at the available values for target .

Further expansion for other popular target values

Multiple Targets

Although webpack not to support the target incoming multiple strings, you can create a homogenous library by packing two separate configurations:

Webpack.config.js
const path = require('path');
const serverConfig = {
 target: 'node',
 output: {
   path: path.resolve(__dirname, 'dist'),
   filename: 'lib.node.js'
 }
 //…
};

const clientConfig = {
 target: 'web', // <=== The default is 'web', which can be omitted
 output: {
   path: path.resolve(__dirname, 'dist'),
   filename: 'lib.js'
 }
 //…
};

module.exports = [ serverConfig, clientConfig ];

The above example will you dist create folder lib.js and lib.node.js file.

Resource

As you can see from the above options, there are several different deployments_targets to choose from. Below is a list of examples and resources you can refer to.

Webpack Hot Module Replacement

The HMR – Hot Module Replacement feature replaces, adds, or removes modules while the application is running , without having to reload the entire page. Mainly through the following ways to significantly speed up the development:

  • Retains the state of the application that was lost when the page was completely reloaded.
  • Only update changes to save valuable development time.
  • Adjusting the style is faster – almost equivalent to changing the style in the browser debugger.

How does all this work?

Let’s look at it from a few different perspectives to understand how HMR works…

In the application

The following steps can be used to swap in and out modules in an application:

  1. The application code requires the HMR runtime to check for updates.
  2. The HMR runtime (asynchronous) downloads the update and then notifies the application code.
  3. The application code requires the HMR runtime to apply the update.
  4. HMR runtime (asynchronous) application update.

You can set HMR so that this process automatically triggers an update, or you can choose to require updates when the user interacts.

In the Compiler

In addition to common resources, the compiler needs to issue an “update” to allow the previous version to be updated to the new version. “update” consists of two parts:

  1. Updated manifest (JSON)
  2. One or more updated chunks (JavaScript)

The manifest includes the new compiled hash and all the chunk directories to be updated. Each update chunk contains code for all update modules (or a flag to indicate that the module is to be removed) corresponding to this chunk.

The compiler ensures that the module ID and chunk ID are consistent between these builds. These IDs are usually stored in memory (for example, when using webpack-dev-server ), but they may also be stored in a JSON file.

In the Module

HMR is an optional feature that only affects modules that contain HMR code. For example, by style-loader as style style additional patches. In order to run the append patch, style-loader the HMR interface is implemented; when it receives the update via HMR, it replaces the old style with the new style.

Similarly, when the HMR interface is implemented in a module, you can describe what happens when the module is updated. However, in most cases, there is no need to force the HMR code to be written in each module. If a module does not have an HMR handler, the update will bubble. This means that a simple handler can update the entire module tree. If a separate module is updated in this module tree, the entire set of dependent modules will be reloaded.

About module.hot interface details, see the HMR API page .

In HMR Runtime

These things are more technical… If you are not interested in it internally, you can skip to the HMR API page or the HMR guide at any time .

For runtime module system, additional codes are sent to parents and children tracking module. On the management side, runtime supports two methods check and apply.

Check Send an HTTP request to update the manifest. If the request fails, there is no update available. If the request is successful, the chunk to be updated will be compared to the currently loaded chunk. For each loaded chunk, the corresponding chunk to be updated is downloaded. When the download is complete all pending updates chunk, you will be ready to switch to the readystate.

Apply The method marks all updated modules as invalid. For each invalid module, you need to have an update handler in the module, or an update handler in its parent module. Otherwise, the invalid tag is bubbling and also invalidating the parent. Each bubbling continues until the application entry start point is reached, or to the module with the update handler (whichever comes first). This process fails if it bubbling from the beginning of the entry.

After that, all invalid modules are processed and unloaded (via the dispose handler). Then update the current hash and call all “accept” handlers. The runtime switches back to 闲置state and everything continues as usual.

Getting Started with HMR

HMR can be used as a replacement for LiveReload during development. webpack-dev-server support hotmode, before attempting to reload the entire page, the heating mode will try to use the HMR to update. See the module hot update guide for more details .Like many other features, the power of webpack is its customizable. There are many ways to configure HMR depending on your specific project needs . However, for most implementations, webpack-dev-server it works well and allows you to get started quickly with HMR.

Related JavaScript Tutorials For Beginners

JavaScript Introduction Tutorials
Introduction to JavaScript
Javascript Reference and Specifications
Javascript Code editors
Javascript Developer Console
Javascript Basics
JavaScript Hello World.!
External JavaScript Files
JavaScript Code Structure
Use Strict in JavaScript

RxJS Tutorial For Beginners

RxJS Tutorial from Codingcompiler. RxJS is a responsive programming library that uses Observables to make writing asynchronous or callback-based code easier. This project is a rewrite of Reactive-Extensions/RxJS (RxJS 4) with better performance, better modularity, better debug call stack, while maintaining most backwards compatibility, with only some destructive changes. (breaking changes) is to reduce the outer layer of the API.

Continue reading “RxJS Tutorial For Beginners”

JavaScript Variables

Variables in JavaScript

JavaScript Variables Tutorial from Coding compiler. Depending on what you are doing the script, you will need to work with the information. If this is an electronic store, then this is a goods basket. If the chat – visitors, messages and so on.

Variables are used to store information .

Continue reading “JavaScript Variables”

Modern standard “use strict” in JavaScript

JavaScript “use strict”

Modern standard “use strict” in JavaScript tutorial from Coding compiler. For a very long time, the JavaScript language developed without losing compatibility. New features were added to the language, but the old – never changed, so as not to “break” the already existing HTML / JS-pages with their use.

Continue reading “Modern standard “use strict” in JavaScript”

React Tutorial For Beginners

React tutorial from Codingcompiler. React is a JAVASCRIPT library for building user interfaces. React is mainly used to build UI, and many people think React is a V (view) in MVC.

React originated from Facebook’s internal project, used to build Instagram sites, and was open sourced in May 2013. React has high performance, code logic is very simple, and more and more people have begun to pay attention to and use it. Let’s start learning React JavaScript.

Continue reading “React Tutorial For Beginners”

VueJS Tutorial For Beginners

VueJs Tutorial from Codingcompiler. Here in this Vue tutorial we discuss most of the basic functions of the Vue core. Let’s start learning Vue JavaScript.

Continue reading “VueJS Tutorial For Beginners”

JavaScript Code Structure

Code Structure of JavaScript

In this Codingcompiler JavaScript tutorial, we will look at the general structure of the code, the commands and their separation. Let’s start learning JavaScript.

Continue reading “JavaScript Code Structure”