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

Js ESM specification example analysis, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

With the development of the front end, the community ecology has been very rich.

Thanks to the efforts of countless open source gods, many front-end development pain points (such as "static type checking", "browser compatibility") already have de facto standard solutions (such as TS, babel).

However, under this prosperity, there is a problem that daily development is not easy to perceive:

The confusion of modular specifications

Have you ever encountered an inexplicable bug, searched for resources in many ways, verified it over and over again, and finally found out after several hours:

It turns out that a package exports CJS, and the project uses ESM to cause.

For example, this example: remember a package compression error [1]

If you think this is an easy-to-find problem, consider combining layers of dependencies with node_modules?

This problem uncovers the tip of the iceberg of the struggle and game between modular norms.

As the cornerstone of modern front-end engineering, modular specification has too much to study.

I will spend a few articles explaining the modular specification. This is the first article that will focus on the evolution of modular specifications.

Text

What was the biggest headache in the front end ten years ago? It must be browser compatibility.

With the emergence of compilation tools such as babel, compatibility is gradually solved by engineering solutions (ES6+ compiled to ES5).

Not only the "compatibility" problem, but also the rigid requirements of day-to-day development, such as DSL (such as JSX, VUE template syntax), code compression, code static checking (TS), can be found in engineering solutions.

If the front-end engineering ecology of today's prosperity is compared to a building, the foundation of the building must be a "modular specification".

Modern JS code is organized based on the "modular specification". Let's take a look at the building from the bottom up:

The implementation of the specification depends on the host environment, such as the browser environment that implements the EcmaScript Module (hereinafter referred to as ESM) specification.

Node V12 previously supported the CommonJS (later referred to as CJS) specification, and later supported both CJS and ESM.

On top of the "hosting environment" is a "toolset" based on modular specifications, such as webpack, vite, and VScode ecology.

Furthermore, a variety of engineering tools can be implemented based on the API provided by the toolset. For example:

Webpack loader

VScode plugin

Babel plugin

Further up is the business code written by the developers themselves.

Developers only need to configure the tools in the toolset to provide services for business code. For example:

Configure eslint (tools) in VScode (tool set), and you can get the corresponding prompts at development time.

By configuring babel loader (tools) in webpack, you can use ES6+ syntax during development.

It can be seen that, ideally, there is no need to pay attention to the underlying "modular specification" implementation from the developer's perspective.

The dispute of norms

However, things are dynamic, and modular specifications are not achieved overnight, so let's go back to 2009.

American programmer "Ryan Dahl" created the node.js project, which uses JS for server-side development.

Node.js uses the CJS [2] standard as the modular specification.

With the server-side module specification (CJS), it is natural that JS developers want to provide a modular specification for clients (mainly browsers).

However, CJS is designed for the server side.

On the server side, IO operations are usually completed quickly, so the CJS specification defines:

Module loading-- > module parsing-- > module execution

The process is executed synchronously as a whole.

However, in a browser environment, "module loading" (that is, data requests) is usually time-consuming. Someone once made a vivid analogy:

If a CPU cycle takes 1 second to complete, the network request for a file can take 4 years.

It is clear that the browser side needs a modular specification that "supports asynchronism".

AMD (Asynchronous Module Definition Asynchronous Module definition) specification is the product of such requirements.

However, the norms put forward by these communities are only to meet the temporary needs after all. with the development of history, new modular norms continue to pour in and disappear.

Until the ESM specification was proposed.

The ESM specification is a modular specification of the ES standard, and its early discussion dates back to 2009.

You can see the history of the ESM specification here, es-module-history [3]

ESM divides the module specification into three phases:

Module loading-- > module instantiation-- > module execution

Where "module loading" is done by loader provided by the hosting environment (for example, in a browser environment, the behavior of loader is defined by the HTML specification [4]).

Module instantiation and module execution are defined by the ESM specification.

Different from the synchronous execution of the CJS specification, the ESM specification disassembles the process into three separate phases.

Whether the module load is synchronous or asynchronous is determined by the host environment.

Support different host environments, smooth out multi-terminal differences, and be more powerful than other specifications (described later), plus pure pedigree (officially proposed by ES)

Make the ESM specification unified front-end "seems" just around the corner.

However, at this time, the community already has a large number of open source packages and components based on the CJS specification, and they cannot immediately switch to the ESM specification.

Therefore, the current situation of JS ecology is that the libraries of CJS specifications and ESM specifications will coexist and will be in a state of coexistence for a long time.

But in the end, the ESM specification is bound to dominate, after all, it has too many advantages (again, described later).

Opportunities brought about by the fragmentation of norms

The current confusion of modular specifications is an opportunity for open source bosses.

In order to enable developers to focus more on the business, rather than on the adaptation of module specifications.

Many open source "toolsets" try to smooth out modularization differences, such as:

Using babel-plugin-transform-commonjs in babel can convert the code of CJS specification into ESM specification.

In order to solve the current incompatibility of ESM, CJS and browser script tag import, a UMD (Universal Module Definition) specification compatible with the three formats is proposed.

Some "toolsets" take advantage of the differences in modular specifications to compete with other competitors, such as:

The selling point of the browserify packaging tool is to use the CJS specification to package so that a piece of code executes in both the Node environment and the browser environment (after packaging).

Among them, in the browser environment, some core libraries of Node (such as events, stream, path...) Will be packaged into a version supported by the browser.

Vite uses the ESM specification to build dependencies between modules in a DEV environment.

Relying on most modern browsers to support the ESM specification natively, the process of packaging is omitted and the compilation speed is greatly improved.

Rollup natively provides more support for ESM.

Strictly support the ESM specification, and provide better static analysis, so that rollup once provided better performance treeShaking capabilities.

Become the first choice for more library packaging tools.

Compete differently with large and comprehensive solutions such as webpack.

The pain caused by the separation of norms

As you can see, due to the separation of modular specification support from the underlying hosting environment, the upper toolset is needed to smooth out the differences in module specifications.

Imagine a project that uses both webpack, babel, and TS.

All three toolsets are compatible with a variety of module specifications. For example:

When using babel alone, for the following code:

Import a from 'lib'; console.log (a)

Will be compiled by babel into:

"use strict"; var _ lib = _ interopRequireDefault (require ("lib")); function _ interopRequireDefault (obj) {return obj & & obj.__esModule? Obj: {default: obj};} console.log (_ lib.default)

The default Export of ESM is compiled to an object that contains the default property.

You can open babel playground [5] to try.

When multiple "toolsets" are in the same project, doing the same thing for their own purposes (erasing differences in modular specifications)

Once a plug-in configuration in the toolchain doesn't live up to expectations, or introduces a package that doesn't live up to expectations, the tough debug begins.

Dawn even if there are many inconveniences at present, the process of history is unstoppable, and the modular norms that have been left behind and crushed by the great wheel of history will gradually disappear in the eyes of developers.

After reading the above, have you mastered the method of example analysis of the ESM specification in js? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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