This is the 17th day of my participation in the August Text Challenge.More challenges in August

Package and NPM

Node organizes its own core modules and allows third-party file modules to be written and used in an orderly manner.

However, in third-party modules, modules are still hashed everywhere and cannot be directly referenced to each other

So outside of modules, packages and NPMS are the mechanisms that link modules together.

  • Schematic diagram of package organization module
graph LR; Subgraph package d1 [the module] -. - > | the require | d10 d2. [the module] - [export module] - > | the require | d10 d3 [the module] - [export module] - > | the require | d10 export module] [end d10 [export module] . -- - > | the require | d [the module]

CommonJS package specification definition is actually very simple, by the package structure and package description file two parts.

Package structure

Used to organize various files in a package, is an archive file, that is, a directory packaged directly as a. Zip or tar.gz file.

Compliant package directory:

  • Package. json: package description file
  • Bin: directory for storing executable binary files
  • Lib: a directory for storing JavaScript code
  • Doc: Directory for storing documents
  • Test: Code used to store unit test cases

Package. json package description file

All NPM behavior is related to the fields in the package description file

Some fields:

  • Name: the package name. The specification definition should consist of lowercase letters and numbers, with no Spaces allowed. Package names must be unique to avoid overlapping conflicts when they are published

  • Description: introduction of package

  • Version: The version number, about which is also mentioned in Node.js Learning (1) – Introduction

  • Keywords: keyword group, mainly used for classification search in NPM.

  • Maintainers: List of package maintainers. Each maintainer consists of three attributes: name, email, and Web. NPM authenticates permissions through this property.

    Format:

        "maintainers": [{"name":"kongchengji"."email":"[email protected]"."web":"[http:](https://blog.csdn.net/qq_36171287)" }]
Copy the code

  • Ficolin-3: List of contributors, in the same format as the list of maintainers

  • Bugs: a web address or email address that can be used to report bugs

  • Licenses: List of licenses used by the current package, indicating which licenses the package is used under

    Format:

     "licenses": [{"type": "GPLv2"."url":"" }]
 / / or
 "license": "ISC"
Copy the code

  • Repositories: A list of locations of hosted source code, indicating how and where package source code can be accessed. Format:

    "repository": {
"type": "git"."url": "git+https://github.com/kongchengji/UiSelfMade.git"
},
Copy the code

  • Dependencies: List of packages that use the current package. This property is very important

  • Homepage: the website address of the current package

  • OS: The operating system supports lists. If the list is empty, no assumptions are made for the operating system

  • Cpi: list of SUPPORTED CPU architectures

  • Engine: List of supported JavaScript engines

  • Directories: specifies the package directory

  • Implements: List of implemented specifications. Flags which CommonJS specifications are implemented by the current package

  • Scripts: script description object. Mainly used by package managers to install, compile, test, and uninstall packages

    Format:

        "scripts": {
        "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js"."start": "npm run dev"."lint": "eslint --ext .js,.vue src"."build": "node build/build.js"
    },
Copy the code

NPM differs from the package specification by adding four fields:

  • Author :ok_man:
  • Bin: Some package authors want packages to be used as command-line tools.
  • Main: When a module imports a package, it checks this field in a limited way and uses it as an entry module to the rest of the modules in the package. If not, require will look for index.js, index.node, and index.json in the package directory as the default entry
  • DevDependencies: Some modules need dependencies only at development time.

    DevDependencies: Used in the development environment Dependencies: Used in the production environment




The front and back ends share modules

With the advent of JavaScript in Node, one advantage is that some modules can be shared between the front and back ends.

Sweat_drops :sweat_drops: sweat_drops:

Focus on the front and rear modules

The front and back JavaScript sits on both sides of the HTPP and plays different roles.

JavaScript on the browser side needs to be distributed from the same server side to multiple clients. The bottleneck is bandwidth. Loading code from the network

In the front end JavaScript, the AMD specification is mostly used.

CommonJS is not completely suitable for front-end JavaScript, such as Node module import is basically synchronous, but if front-end import uses synchronous import, the UI initialization process will spend a lot of time waiting for the script to load.

AMD specification

The AMD specification is an extension of the CommonJS specification. Its full name is Asynchronous Module Definition. Is an asynchronous module definition

Module definition: define(ID? , dependencies? , factory); Id is the name of the module, which is an optional parameter.

Dependencies specifies a list of modules to depend on, which is an array and an optional parameter

AMD needs to specify all dependencies when declaring a module, passing the dependencies to the module contents with parameters:

define(['./a'.'./b'].function (dep1, dep2) {
    a.doSomethimg()
    b.doSomething()
});
Copy the code

CMD specification

The opposite of the AMD specification is the CMD specification, full name: Common Module Definition. Is a public module definition

This was put forward by yu Bo (also a big man) in China

Module definition: Define (Factory)

CMD supports dynamic import:

define(function(require.exports.module) {
    var a=require('./a')
    a.doSomethimg()
    var b=require('./b')
    b.doSomething()
})
Copy the code

Whenever you need to rely on a module, just call require() to introduce it

  • CMD advocates dependence on nearby; AMD believes in relying on the front end
  • CMD is deferred execution; AMD is ahead of schedule
  • CMD performs well because it is executed only when the user needs it; AMD user experience is good, because there is no latency, dependency modules are executed ahead of schedule

The biggest difference between AMD and CMD is the execution timing of dependent modules

Compatible with various module specifications

Create a Hello method that runs in different operating environments, including Node, AMD, CMD, and common browsers

  • Add one before the anonymous function; It’s a good convention that name is the method name and definition is the method body
  • throughtypeofCheck whether the environment is AMD or CMD or Node
  • You can mount the module execution result in the window variable so that it can be called directly
// Add one before the anonymous function; It's a good convention that name is the method name and definition is the method body; (function (name, definition) {
    // Check whether the environment is AMD or CMD
    var hasDefine = typeof define === 'function'.// Check whether the environment is Node
    hasExports = typeof module! = ='undefined' && mudule.exports;

    if(hasDefine) {
        define(definition);
    } else if (hasExports) {
        module.exports = definition();
    } else {
        // Hang the module's execution result in the window variable. In the browser, this points to the window object
        this[name] = definition();
    }
})('hello'.function () {
    var hello = function () {
        console.log('hello');
    }
    return hello;
});
Copy the code