​​摘要：包与 NPM Node 组织了自身的核心模块，也使得第三方文件模块可以有序的编写和使用。

本文分享自华为云社区《NodeJs深入浅出之旅：包与NPM》，作者：空城机。

包与 NPM

Node 组织了自身的核心模块，也使得第三方文件模块可以有序的编写和使用。

但是在第三方模块中，模块与模块之间仍然是散列在各地的，相互之间不能直接引用

所以在模块外，包和 NPM 是将模块联系起来的机制。

• 包组织模块示意图

​CommonJS 的包规范定义其实也很简单，由包结构和包描述文件两部分组成。

包结构

用于组织包中的各种文件，是一个存档文件，即一个目录直接打包为.zip 或 tar.gz 格式的文件。

符合规范的包目录：

• package.json: 包描述文件

• bin: 用于存放可执行二进制文件的目录

• lib: 用于存放 JavaScript 代码的目录

• doc: 用于存放文档的目录

• test: 用于存放单元测试用例的代码

package.json 包描述文件

NPM 所有行为都与包描述文件的字段息息相关

一些字段：

• name: 包名。 规范定义需要用小写的字母和数字组成，不允许出现空格。 包名必须是唯一的，以免对外公布时产生重名冲突

• description: 包简介

• version: 版本号，关于其介绍在《Node.js 学习（一）——简介》也有提及

• keywords: 关键字数组， NPM 中主要用来作分类搜索。

• maintainers: 包维护者列表。 每个维护者由 name、email 和 web 这 3 个属性组成。 NPM 通过这个属性进行权限认证。

格式：

"maintainers":[{ "name":"kongchengji", "email":"111@.com", "web":"[http:](https://blog.csdn.net/qq_36171287)" }]

• contributors: 贡献者列表，格式与维护者列表相同

• bugs: 一个可以反馈 bug 的网页地址或邮件地址

• licenses: 当前包所使用的许可证列表，表示包在哪些许可证下使用

格式：

 "licenses":[{ "type": "GPLv2", "url":"" }] // 或者 "license": "ISC"

• repositories: 托管源代码的位置列表，表明可以通过哪些方式和地址访问包源代码。

格式：

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

• dependencies: 使用当前包所需要依赖的包列表。 这个属性非常重要

• homepage: 当前包的网站地址

• os: 操作系统支持列表， 如果列表为空，则不对操作系统做任何假设

• cpi: CPU 架构支持列表

• engine：支持的 JavaScript 引擎列表

• directories：包目录说明

• implements： 实施规范的列表。 标志当前包实现了 CommonJS 哪些规范

• scripts： 脚本说明对象。 主要用于被包管理器用来安装、编译、测试和卸载包

格式：

"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"    },

​NPM 与包规范区别在于多了四个字段：

• author： 包作者 :ok_man:

• bin: 一些包作者希望包可以作为命令行工具使用。

• main: 模块引入包时，会有限检查这个字段，并将其作为包中其余模块的入口模块。 如果不存在，require 会查找包目录下的 index.js、index.node、index.json 作为默认入口

• devDependencies： 一些模块只在开发时需要依赖。

devDependencies：开发环境使用 dependencies：生产环境使用

前后端共用模块

JavaScript 在 Node 出现后，有一项优势 --> 一些模块可以在前后端实现共用。

但是前后端上始终还是有一些差别的 :sweat_drops:

前后端模块侧重点

前后端 JavaScript 分别搁置在 HTPP 的两端，扮演的角色并不同。

浏览器端的 JavaScript 需要经历从同一个服务器端分发到多个客户端执行，瓶颈是带宽，从网络加载代码服务器端的 JavaScript 是相同代码需要多次执行，瓶颈是 CPU 和内存等资源，从磁盘中加载

在前端 JavaScript 中，主要还是应用 AMD 规范。

CommonJS 并不完全适用于前端 JavaScript，比如 Node 的模块引入基本是同步的，但是前端引入如果使用同步引入，UI 在初始化过程中需要花费很多时间等待脚本加载完成。

AMD 规范

AMD 规范是 CommonJS 规范的一个延伸，全称：Asynchronous Module Definition。

是异步模块定义

模块定义：define(id?,dependencies?, factory);

id 是模块的名字，它是可选的参数。

dependencies 指定了所要依赖的模块列表，它是一个数组，也是可选的参数

AMD 需要在声明模块时指定所有的依赖，通过形参传递依赖到模块内容中：

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

CMD 规范

与 AMD 规范相对的还有 CMD 规范，全称：CommonModule Definition。

是公共模块定义

这是由国内的玉伯（也是一位大佬）提出的

模块定义：define(factory)

CMD 支持动态引入：

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

在需要依赖模块时，随时调用 require()引入即可

• CMD 推崇依赖就近; AMD 推崇依赖前置

• CMD 是延迟执行; AMD 是提前执行

• CMD 性能好,因为只有用户需要的时候才执行; AMD 用户体验好,因为没有延迟,依赖模块提前执行了

AMD 和 CMD 最大的区别是对依赖模块的执行时机处理不同

兼容多种模块规范

创建一个 hello 方法，让 hello 方法能在不同运行环境中运行，兼容 Node、AMD、CMD 和常见浏览器

• 匿名函数前加一个;是个好习惯 name 是方法名，definition 是方法体

• 通过 typeof 检测环境是否为 AMD 或 CMD 还是 Node 环境

• 可以将模块执行结果挂载在 window 变量中，这样可以直接调用

// 匿名函数前加一个;是个好习惯  name是方法名，definition是方法体;(function (name, definition) {    //检查环境是否是AMD或CMD    var hasDefine = typeof define === 'function',    // 检查环境是否为Node    hasExports = typeof module !== 'undefined' && mudule.exports;
    if(hasDefine) {        define(definition);    } else if (hasExports) {        module.exports = definition();    } else {        // 将模块的执行结果挂在window变量中，在浏览器中this指向window对象        this[name] = definition();    }})('hello', function () {    var hello = function () {        console.log('hello');    }    return hello;});

点击关注，第一时间了解华为云新鲜技术~