ES6 's modules, build tools, and application releases

Inch log
Links: https://zhuanlan.zhihu.com/p/19569085
Source: Know
Copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please specify the source.

In general, it is written according to future standards and is now adapted with tools.

we already have a dependency management solution for the server

1. Install and declare dependencies;
2. Get (require) dependencies in the code;
3. Package and publish common code to the same place. (NPM, gems, etc.)

browser-side dependency management is far from complete, and things look awful right now .

1. Have a variety of module specifications;
2. There are many package management tools;
3. Generic code is packaged and released everywhere, and users are still very inconvenient to use them.

It's important .

We need to get rid of this problem-when someone has a angular directive, a ember component, a Web component, or an old but useful JavaScript class library, they need a simple way to share the code. Node is successful in this because NPM is easy to use.

Using third-party code in node is simple.

1. Run the NPM install backbone in the CLI to mount the backbone;
2. Use the Backbone in your program by using var Backbone = require (' Backbone ') .

I want to do this on the browser side, but first:

we have three ways to distribute it.

1. (The usual practice is) to load the entire program at once;
2. Gradual loading of partial packaging (also very common);
3. Completely non-packaged (though feasible, but most pit-daddy).

Program Packaging policy is not the same

1. Configuration merge
1. Load the entire directory;
2. Add the displayed configuration, specifying the load order.
2. Dependency analysis (R.js, browserify)
1. This is the way the server is used, but not packaged;
2. The key behind the whole package is to create a module runtime for the browser.

Program Sub-publication

Depending on how the program is distributed and the packaging strategy, we get the following table:

Cjs/globals can also implement local loading of a program through $.getscript or similar tools, but this is not part of the module specification.

Previously, as you can see, I support AMD because it supports all scenarios. Although AMD has received a lot of attention, it has not been accepted by all class library authors, package managers, and JavaScript runtime environments.

Existing tools do not handle all of these usage scenarios. You have to use the specifications that you rely on for the tools you rely on, and the class libraries you depend on need to do the same.

We need a modular specification that can be adapted to existing tools

1. Global, non-declared, unable to use tools to analyze dependencies, no;
2. AMD, Pit Daddy, not all of them fit it;
3. CJS, and does not meet all of the program distribution methods.

So, whatever you choose for your program, you have to hack for those third-party modules on the hour, because these modules do not meet the module system you use

Until UMD "turned out".

What is umd!

A long time ago, I and a few children's shoes (https://github.com/umdjs? Tab=members) proposes one of the most desperate JavaScript module specifications-Universal module Definition.

Like its name means, this specification can basically work in any module environment.

If backbone, Ember, moment, angular, or someone's piece of code is written in the UMD specification, then you use any of the existing front-end tools on them. For example, you can:

1. Choose AMD, install with Bower, build with R.js;
2. As with 1, do not build;
3. Choose Commonjs, install with NPM, install with browserify;
4. Choose AMD, install with NPM, r.js build;
5. What specifications are not used, directly using script to refer to the page;
6. Use components that have support for UMD.

I can make a cross-table that contains all the module formats, package managers, and build tools. But you should be aware that because it supports all existing tools, it supports the way all programs are distributed.

But there is a problem, UMD let the automatic correction become very messy, I did not lie, for example, here is a very bad way to use backbone:

(function (root, factory) {  if (typeof define === ‘function‘ && define.amd) {    // AMD    define(‘backbone‘, [‘jquery‘, ‘underscore‘], function (jQuery, _) {      return factory(jQuery, _);    });  } else if (typeof exports === ‘object‘) {  // Node.js    module.exports = factory(require(‘jquery‘), require(‘underscore‘));  } else {    // Browser globals    root.Backbone = factory(root.jQuery, root._);  }}(this, function (jQuery, _) {  var Backbone = {};  // Backbone code that depends on jQuery and _  return Backbone;}));

You can see why this is not popular, it is too scary, no one will write, look at it, I just want to curse.

use ES6, compile into UMD, use everywhere

The ES6 module specification appears so that class library developers can use ES6 to write code and then turn it into UMD format, where they can go (NPM, Bower, and so on).

1. This is as good as the unstructured cjs, even more than CJS;
2. This is the future, anyway, you end up going to use this model.

What's worse now is for Umdjs/es6-module-transpiler. GitHub adds support for UMD, which is exactly what https://twitter.com/machty and I are doing.

This requires the support of the class library author

This could be a very arduous battle, but:

1. Anyone interested in browser-side modularity can see its benefits;
2. Eventually ES6 will land, there is a platform to encourage people to do so;
3. We can fork or shim their repos, then let the module manager use this fork or shim (Bower has always done so).

Future

The first step is to allow the class library author to support ES6;

The second step, let the module manager support ES5, and compile for us;

The third step is to wait for the es6 to ground.

We can!

Please pay attention to Umdjs/es6-module-transpiler GitHub, waiting for us to fix UMD, we'll give you a couple of examples.

Original: ES6 Modules, Build Tools and Browser App Delivery? Ryan Florence Online

JavaScript node. js ECMAScript 6

ES6 's modules, build tools, and application releases