如果不了解npm和ES6模块那就看过来.docx

JavaScript 的格局日新月异,网站和应用的依赖关系也随之而变。
这篇文章适合那些大量使用 script 标签来加载 JS 的程序员,随着网页数目增多和项目规模的扩大,他们感觉到依赖管理变得越来越笨重。
如果想要深入了解每一个细节,monJS 和 AMD 规范做比较的话,请参考 Axel Rauschmayer 的 Exploring ES6 book , 尤其是第 17 章。
什么是 JavaScript 模块?
JavaScript 模块允许我们把项目中的代码分散成一个个单独的文件,或者使用通过 npm 安装的开源模块。用模块化的方式写代码有助于(项目的)组织、维护、测试,以及最重要的依赖管理。
当我们编写 JavaScript 时,理想情况是保障每个模块都专注一件事并把这件事做好。这种分工可以让我们在需要某个模块时再去做相应的加载。模块化是是 npm 背后的核心原则。当需要某个特定的功能时,我们能安装相应的模块并加载到应用当中。
随着时间推移,我们发现那种大而全的框架变少了,看到更多的是 专注一件事并把这件事做好 的小型模块。
举个例子,大部分人都用过 jQuery。这个库包含了从 CSS 操作到 ajax 调用几乎全部的方法。现如今,很多人开始迁移到 React 这类库上,我们常常需要加载额外的模块来完成一些任务如 ajax 或路由。
这篇文章将会带你大致了解 npm 和 ES6 模块的使用。对于其它一些的包管理(如 Bower) 和模块加载工具(monJS 和 AMD),已经有大量的文章和话题在讨论了。
不管你是做 Node 开发还是前端开发,我相信 ES6 模块和 npm 是未来的方向。如果你去看当下流行的开源项目,像 React 或 lodash,你会发现他们都采用了 ES6 模块+ npm。
当前的开发流程
很多 JavaScript 的开发流程是这样的:
找一个符合要求的插件或库然后从 GitHub 上下载。
通过 script 标签加载到网站。
用全局变量调用或以 jQuery 插件的方式调用。
这类开发流程这么多年来表现一直不错,除了这几个问题:
插件必须手动升级- 很难及时得知(该插件)何时修复了严重的bug或是有哪些新功能可用。
混乱的源代码版本控制 - 所有依赖都要加入源代码,当库更新时会导致非常不愉快的结果(版本问题)。
基本没有依赖管理- 很多脚本的功能是重复的,如果分成小模块则可以很轻松的实现共享。
代码污染和潜在的全局命名空间冲突。
编写模块化的 JavaScript 这种理念并不新鲜,不过随着 ES6 的到来和业界将 npm 作为 JavaScript 的首选包管理工具,我们看到大量的开发摒弃了从前的工作流程,迁移到使用 ES6 和 npm 的标准化流程上来。
等等,npm?那不是 Node 专用的吗?
很久以前,npm 是作为 的包管理工具起步的,如今它已经进化为JavaScript和前端开发的包管理工具。现在,我们可以把库的安装过程简化为 2 个步骤:
从 npm 安装依赖,例如:
JavaScript
1
npm install lodash --save
在当前文件中导入刚才的依赖,例如:
JavaScript
1
import _ from 'lodash';
这套开发流程还需要很多的工作要做,同时关于模块的导入导出也有很多需要学习,现在让我们来深入了解一下吧。
模块背后的理念
我们使用导入和导出语句来在文件之间共享代码(变量、函数、数据、任何代码),而不是把所有代码加载到全局命名空间下。每一个模块导入需要的依赖,也可以为其它文件导出需要的代码。
让代码在浏览器运行还需要一个打包的步骤,我们会在文章的后面加以讨论,现在,让我们专注于 JavaScript 模块背后的核心理念。
创建自己的模块
假设我们正在构建一个在线购物的应用,需要一个文件存放所有的辅助函数。我们可以创建一个模块命名为 ,文件包含一些辅助函数- formatPrice(price)、 addTax(price) 和 discountPrice(price, percentage),还有一些关于该在线商城的变量。
我们的 文件看起来如下:
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
const taxRate = ;
 
const couponCodes = ['BLACKFRIDAY', 'FREESHIP', 'HOHOHO'];
 
function format