Usage and difference of Js module packaging exports require import

1. Commonjs exports and require usage

Commonejs stipulates that each file is a module. The biggest difference between introducing a JavaScript file directly into the page through the script tag and encapsulating it into a CommonJS module is that the top-level scope of the former is the global scope, which will pollute the global environment when declaring variables and functions; while the latter will form a scope belonging to the module itself, and all variables and functions can only be accessed by the module itself and are not visible to the outside world.

1.1 CommonJS export module.exports

Exports are the only way a module exposes itself to the outside world. In CommonJS, you can export the contents of a module through module.exports, such as:

module.exports = {
    name: 'commonJS_exports.js',
    add: function(a, b){
        return a + b;
    }
}

For ease of writing, CommonJS also supports another simplified export method: using exports directly. The effect is the same as above:

exports.name = 'commonJS_exports.js';
exports.add = function(a, b){
    return a + b;
}

Note: Do not mix module.exports with exports when exporting. Here is an incorrect example:

exports.add = function(a, b){
    return a + b;
}
module.exports = {
    name: 'commonJS_exports.js'
}

The above code first exports the add attribute through exports, and then reassigns module.exports to another object. This will cause the object that originally had the add attribute to be lost, and only name will be exported. Therefore, it is recommended that the export method in a module should either use module.exports or use exports, and do not mix them together.

In actual use, in order to improve readability, module.exports and exports statements should be placed at the end of the module.

1.2 CommonJS import require

Use require to import modules in CommonJS. commonJS_exports.js export code:

console.log('...hello, I am commonJS_exports.js....start..')
//1. The first way to write module.exports = {
    name: 'commonJS_exports.js',
    add: function(a, b){
        return a + b;
    }
}

Import code in PageModule.vue page:

//1. Test CommonJS exports and require
var comObj = require('../api/module/commonJS_exports');
console.log('...name: ', comObj.name);
try{
      console.log('8 + 9 = ', comObj.add(8, 9));
}catch(e){
      console.log(e);
}

In addition, if the same module is imported multiple times in a page, the module will only be executed the first time it is imported. Subsequent imports will not be executed, but the results of the last execution will be directly exported. Here is an example:

var comObj = require('../api/module/commonJS_exports');
                //Call the import again and find that the imported module will not be executed again, but the result obtained after the last execution will be directly exported require('../api/module/commonJS_exports');

console.log('...name: ', comObj.name);
try{
      console.log('8 + 9 = ', comObj.add(8, 9));
}catch(e){
      console.log(e);
}

We can see the following console print results, and the import module is indeed executed only once:

....test CommonJS imports...

...name: commonJS_exports.js

8 + 9 = 17

There is a property loaded in the module object that is used to record whether the module has been loaded. Its default value is false. When the module is loaded and executed for the first time, it will be set to true. When it is loaded again later and module.loaded is checked to be true, the module code will not be executed again.
The require function can receive expressions. With this feature, we can dynamically specify the module loading path.

const moduleNames = ['foo.js', 'bar.js'];
moduleNames.forEach(name=>{
   require('./' + name);
})

2. ES6 Module export and import usage

The module feature was not added until ES6 was released in June 2015. ES6 Module also treats each file as a module. Each module has its own scope. The only difference is the import and export statements. Import and export are also added as reserved keywords in ES6 version (module in CommonJS is not a keyword).

2.1 ES6 Module export

In ES6 Module, use the export command to export the module. There are two export forms:

Named Export

Default Export

2.1.1 There are two different ways to write named exports:

//The first export method: named export //1.1 The first method of named export export const name = 'es6_export.js';
export const add = function(a, b) { return a + b; }

// //1.2 Second way to write named exports // const name = 'es6_export.js'
// const add = function(a, b){ return a + b; }
// export { name, add };

The first way is to declare and export the variable on one line; the second way is to declare the variable first and then export it using the same export statement. The effect of both writing methods is the same. When using named exports, you can also rename the variable using the as keyword. like:

const name = 'es6_export.js'
const add = function(a, b){ return a + b; }
export { name, add as getSum }; // name and getSum when imported

2.1.2 Unlike named exports, a module can have only one default export. like:

//The second export method: default export export default{
    name: 'es6_export',
    add: function(a, b){
        return a + b;
    }
}

We can understand export default as exporting a variable named default to the outside world, so there is no need to declare the variable like "named export", and you can export it directly.

//Export string export default 'this is es6_export.js file '
 //Export class
 export default class {...}
 //Export anonymous function export default function(){ ... }

2.2 ES6 Module export import

ES6 Module uses the import syntax to import modules.

2.2.1 Let's see how to import named export modules

const name = 'es6_export.js'
const add = function(a, b){ return a + b; }
export { name, add };
// import {name, add } from '../api/module/es6_export.js'; //Named export first import method // import * as esObj from '../api/module/es6_export.js'; //Named export second alias overall import method import {name, add as getSum } from '../api/module/es6_export.js'; //Named export third alias import method // //Named export first import method // console.log('name: ', name);
// console.log('12 + 21: ', add(12, 21));

// //Named export second alias import method // console.log('name: ', esObj.name);
// console.log('12 + 21: ', esObj.add(12, 21));

                //Named export, third alias import method console.log('name: ', name);
                console.log('12 + 21: ', getSum(12, 21));

When loading a module with named exports, the import should be followed by a pair of curly braces to wrap the imported variable names, and these variables need to have the same names as the exported variables. The effect of importing variables is equivalent to declaring these variables (name and add) in the current scope, and they cannot be changed, that is, all imported variables are read-only.

In addition, similar to named exports, we can rename the imported variables using the as keyword. When importing multiple variables, we can also use the overall import method. This import * as <myModule> import method can add all imported variables as attributes to the <myModule> object, thereby reducing the impact on the current scope.

2.2.2 Let's look at the import of the default export

//The second export method: default export export default{
    name: 'es6_export.js',
    add: function(a, b){
        return a + b;
    }
}
import esObj from '../api/module/es6_export.js';

// Import test of default named export console.log('name: ', esObj.name);
console.log('12 + 21: ', esObj.add(12, 21));

For the default export, import is followed directly by the variable name, and this name can be freely specified (for example, esObj in this case), which refers to the default exported value in es6_export.js. In principle, it can be understood as follows:

import { default as esObj } from '../api/module/es6_export';

Note: The default export of custom variable names is similar to the named export of global aliases, but the named export global aliases must be followed by * as alias after import, while the default export is directly followed by the custom variable name after import.

Finally, let's look at an example that mixes the two import methods:

import react, {Component} from 'react'

React here corresponds to the default export of the module, and Component is a variable in its named export. Note: React must be written before the curly braces and the order cannot be reversed, otherwise it will cause a syntax error.

2.2.3 Compound writing.

In a project, sometimes you need to export a module immediately after importing it, such as an entry file specifically used to collect all pages or components. At this time, you can use the compound form:

export {name, add} from '../api/module/es6_export.js'

However, the above compound writing currently only supports variables exposed by "named export". The default export has no corresponding composite form, so you can only write the import and export separately:

import esObj from '../api/module/es6_export.js'
export default esObj

3. Differences between CommonJS and ES6 Modules

Above we introduced two forms of module definition, CommonJS and ES6 Module. In actual development, we often mix the two. Let's compare their characteristics:

3.1 Dynamic and static

The most essential difference between CommonJS and ES6 Module is that the former resolves module dependencies "dynamically", while the latter resolves them "statically". Here, "dynamic" means that the establishment of module dependencies occurs during the code running phase; while "static" means that the establishment of module dependencies occurs during the code compiling phase.

Let's first look at an example of CommonJS:

// commonJS_exports.js
module.exports = { name: 'commonJS_exports' }
//PageModule.vue
const name = require('../api/module/commonJS_exports').name;

When the module PageModule.vue loads the module commonJS_exports.js, the code in commonJS_exports.js is executed and its module.exports object is returned as the return value of the require function. And the module path of require can be specified dynamically, and supports passing in an expression. We can even use if statements to determine whether to load a module. Therefore, there is no way to determine explicit dependencies before the CommonJS module is executed, and the import and export of modules occur at the runtime of the code.
For the same example, let's compare the writing method of ES6 Module:

//es6_export.js
export const name = 'es6_export.js';
//PageModule.vue
import { name } from '../api/module/es6_export.js'

The import and export statements of ES6 Module are all declarative. It does not support the import path being an expression, and the import and export statements must be located in the top-level scope of the module (for example, they cannot be placed in an if statement).

Therefore, we say that ES6 Module is a static module structure, and the module dependencies can be analyzed during the compilation phase of ES6 code. It has the following advantages over CommonJS:

• Redundant code detection and elimination. We can use static analysis tools to detect which modules have not been called. For example, when introducing a tool library, often only part of its components or interfaces are used in the project, but it is possible to load its code in its entirety. Module code that is not called will never be executed and becomes redundant code. Static analysis can be used to remove unused modules during packaging to reduce the size of packaged resources.
• Module variable type checking. JavaScript is a dynamically typed language and does not check for type errors (such as calling a function on a string value) before code is executed. The static module structure of ES6 Module helps ensure that the values ​​or interface types passed between modules are correct.
• Compiler optimizations. In dynamic module systems such as CommonJS, no matter which method is used, what is essentially imported is an object, while ES6 Module supports direct import of variables, reducing the reference level and making the program more efficient.

3.2 Value copying and dynamic mapping

When importing a module, CommonJS gets a copy of the exported value; in ES6 Module, it is a dynamic mapping of the value, and this mapping is read-only. example:

//commonJS_exports.js
var count = 0;
module.exports = {
    count: count,
    add: function(a, b){
         count+=1;
         return a + b;
    }
}
 //PageModule.vue
 var count = require('../api/module/commonJS_exports.js').count;
 var add = require('../api/module/commonJS_exports.js').add;
 console.log(count); //0 Here count is a copy of the count value in commonJS_exports.js add(2, 3);
 console.log(count); //0 Changes to the variable value in commonJS_exports.js will not affect the copy value here count += 1;
 console.log(count); //1 The copied value can be changed

The count in PageModule.vue is a copy of the value of count in commonJS_exports.js, so when calling the function, although the value of count in the original calculator.js is changed, it will not affect the copy created when importing in PageModule.vue. On the other hand, changes to imported values ​​are allowed in CommonJS. We can change count and add in PageModule.vue to assign them new values. Again, since the values ​​are copied, these operations will not affect calculator.js itself.

Let's rewrite the above example using ES6 Module:

//es6_export.js
let count = 0;
const add = function(a, b){
    count += 1;
    return a + b;
}
export { count, add }
import {name, add, count } from '../api/module/es6_export';

console.log(count); //0, mapping of count value in es6_export.js add(2, 3);
console.log(count); //1 reflects the change of count value in es6_export.js in real time // count += 1; //Cannot be changed, ReferenceError: count is not defined will be thrown

The above example shows that the variables imported in ES6 Module are actually dynamic mappings of the original values. The count in PageModule.vue is a real-time reflection of the count value in calculator.js. When we change the count value in calculator.js by calling the add function, the count value in PageModule.vue also changes accordingly.

We cannot change the variables imported by ES6 Module. This mapping relationship can be understood as a mirror. We can observe the original objects in real time from the mirror, but we cannot manipulate the image in the mirror.

3.3 Circular Dependencies

A circular dependency is when module A depends on module B, and module B depends on module A. Generally speaking, circular dependencies should be avoided as much as possible in engineering, because from the perspective of software design, one-way dependencies are clearer, while circular dependencies will bring certain complexity. In actual development, circular dependencies sometimes occur without our noticing, because when the complexity of the project rises to a sufficient scale, hidden circular dependencies are likely to appear.

In simple terms, it is easy to detect whether there is a direct circular dependency between modules A and B. But the actual situation is often that A depends on B, B depends on C, C depends on D, and finally, after going around in a circle, D depends on A again. When there are too many intermediate modules, it is difficult to find that there is an implicit circular dependency between A and B.

Therefore, how to deal with circular dependencies is a problem that developers must face.

3.3.1 Let's first look at an example of a circular dependency problem in CommonJS:

//bar.js
const foo = require('./foo.js');
console.log('value of foo: ', foo);
module.exports = 'This is bar.js';
//foo.js
const bar = require('./bar.js');
console.log('value of bar: ', bar);
module.exports = 'This is foo.js';
//PageModule.vue

require('../api/module/foo.js');
 /*
    Print results:
    value of foo: {}
    value of bar: This is bar.js
* */

Why is the value of foo an empty object? Let's review the actual execution sequence of the code from the beginning:

1. PageModule.vue imports foo.js, and starts executing the code in foo.js.

2. The first statement of foo.js imports bar.js. At this time, foo.js will not continue to execute downwards, but will enter the inside of bar.js.

3. foo.js is required in bar.js, which creates a circular dependency. It should be noted that the execution right will not be returned to foo.js here, but its export value, that is, module.exports, will be directly taken. However, since foo.js has not been executed to completion, the exported value is the default empty object at this time. Therefore, when bar.js executes the print statement, we see that the value of foo in the console is an empty object.

4. After bar.js is executed, the execution right is returned to foo.js.

5. foo.js continues to execute from the require statement, prints the value of bar in the console (this value is correct), and the whole process ends

From the above, we can see that although the circularly dependent modules are all executed, the values ​​imported by the modules are not what we want. Let's look at it from the perspective of webpack implementation. After packaging the above example, it is very important to have the following code in the bundle:

//The require function
function __webpack_require__(moduleId){
   if (installedModules[moduleId]) {
        return installedModules[moduleId].exports;
   }
   //Create a new module (and put it into the cache)
   var module = installedModules[moduleId] = {
        i: moduleId,
        l: false,
        exports: {}
   }
    //...
}

When PageModule.vue references foo.js, it is equivalent to executing the __webpack_require__ function, initializing a module object and putting it into installedModules. When bar.js references foo.js again, the function is executed again, but this time the value is taken directly from installedModules. At this time, its module.exports is an empty object. This explains the phenomenon seen in step 3 above.

3.3.2 Next, we rewrite the above problem example using ES6 Module:

//bar_es6.js
import foo from './foo_es6.js';
console.log('value of foo: ', foo);
export default 'This is bar_es6.js';
//foo_es6.js
import bar from './bar_es6.js';
console.log('value of bar: ', bar);
export default 'This is foo_es6.js';
//PageModule.vue
import foo_es6 from '../api/module/foo_es6.js';

/* Print results:
    value of foo: undefined
    value of bar: This is bar_es6.js
* */

Unfortunately, bar_es6.js also cannot get the correct export value of foo_es6.js. The only difference is that unlike CommonJS which exports an empty object by default, the value obtained here is undefined. As mentioned above, when importing a module, CommonJS obtains a copy of the value, while ES6 Module is a dynamic mapping

3.3.3 Let's use the features of ES6 Module to support circular dependencies (correct example):

//bar_es6_2.js
import foo from './foo_es6_2.js';
let invoked = false;
function bar(invoker){
    if (!invoked){
        invoked = true;
        console.log(invoker + ' invokes bar_es6_2.js');
        foo('bar_es6_2.js');
    }
}
export default bar;
//foo_es6_2.js
import bar from './bar_es6_2.js'
function foo(invoker){
    console.log(invoker + ' invokes foo_es6_2.js');
    bar('foo_es6_2.js');
}
export default foo;
import foo_es6_2 from '../api/module/foo_es6_2.js'

foo_es6_2('PageModule.vue');
/* Print results:
    PageModule.vue invokes foo_es6_2.js
    foo_es6_2.js invokes bar_es6_2.js
    bar_es6_2.js invokes foo_es6_2.js
* */

It can be seen that the circularly dependent modules foo_es6_2.js and bar_es6_2.js both obtain the correct export values. Let's analyze the execution process of the code:

1. PageModule.vue imports foo_es6_2.js as the entry point, and starts executing the code in foo_es6_2.js.

2. Import bar_es6_2.js from foo_es6_2.js, and the execution right is given to bar_es6_2.js.

3. Execute to the end in bar_es6_2.js to complete the definition of the bar function. Note that at this point, since foo_es6_2.js has not yet been executed, the value of foo is still undefined.

4. Execution returns to foo_es6_2.js and continues until it ends, completing the definition of the foo function. Due to the dynamic mapping feature of ES6 Module, the value of foo in bar_es6_2.js has changed from undefined to the function we defined. This is the essential difference from CommonJS in solving circular dependencies. What is imported in CommonJS is copied and will not change with the change of the original value in the module.

5. The execution returns to PageModule.vue and calls the foo function. At this time, foo-->bar-->foo will be executed in sequence, and the correct value will be printed in the console.

As can be seen from the above examples, the features of ES6 Module enable it to better support circular dependencies. It is just up to the developer to ensure that the correct export value has been set when the imported value is used.

4. Module packaging principle

Faced with hundreds or thousands of modules in a project, how does webpack organize them in an orderly manner and run them on the browser in the order we expect? Below we will explore the principle.

Let’s use the previous example:

//commonJS_exports.js
module.exports = {
    add: function(a, b){
        return a + b;
    }
}
//PageModule.vue
const comObj = require('../api/module/commonJS_exports');
const sum = comObj.add(2, 3);
console.log('sum: ', sum);

The above code will become the following form after being packaged by Webpack (for readability, only the answer structure of the code is shown here):

//Execute anonymous function immediately (function(modules){
        //Module cache var installedModules = {};
        //Implement require
        function __webpack_require__(moduleId){
            //...
        }
        //Execute entry module loading return __webpack_require__(__webpack__require__.s == 0);
 })({
        //modules: Store all packaged modules in key-value form0: function(module, exports, __webpack_require__){
            //Packaging entry module.exports = __webpack_require__("3qiv");
        },
        "3qiv": function(module, exports, __webpack_require__){
            //PageModule.vue content},
        jkzz: function(module, exports){
            //commonJS_exports.js content}
})

This is the simplest Webpack bundle, but it can clearly show how it connects modules with dependencies together. The above bundle is divided into the following parts:

• The outermost anonymous function is executed immediately. It is used to wrap the entire bundle and constitute its own scope.
• installedModules object. Each module is only executed when it is loaded for the first time, after which its exported values ​​are stored in this object. When it is loaded again, the value is directly taken from here without re-execution.
• __webpack_require__ function. For the implementation of module loading, module import can be completed in the browser by calling __webpack_require__(moduleId).
• modules object. All modules that have dependencies in the project will be placed here in the form of key-value. The key can be understood as the ID of a module, which is composed of a number or a very short hash string; the value is the module entity wrapped by an anonymous function, and the parameters of the anonymous function give each module the ability to export and import.

Next, let's look at how a bundle is executed in a browser:

1. The browser execution environment is initialized in the outermost anonymous function, including the definition of the installedModules object, the __webpack_require__ function, etc., to prepare for the loading and execution of the module.

2. Load the entry module. Each bundle has one and only one entry module. In the above example, PageModule.vue is the entry module, and the browser will start executing from it.

3. Execute module code. If module.exports is executed, the export value of the module is recorded; if the require function (__webpack_require__ to be precise) is encountered in the middle, the execution right will be temporarily handed over, and the body of the __webpack_require__ function will be entered to load the logic of other modules.

4. In __webpack_require__, it will be determined whether the module to be loaded exists in installedModules. If it exists, get the value directly, otherwise go back to step 3 and execute the code of the module to get the exported value.

5. All dependent modules have been executed, and finally the execution right returns to the entry module. When the code of the entry module is executed to the end, it means that the entire bundle is finished.

It is not difficult to see that steps 3 and 4 are a recursive process. Webpack creates an environment for each module to export and import modules, but does not modify the execution logic of the code in essence. Therefore, the order of code execution is exactly the same as the order of module loading. This is the secret of Webpack module packaging.

The above is the detailed content of the usage and differences of Js module packaging exports require import. For more information about Js module packaging, please pay attention to other related articles on 123WORDPRESS.COM!