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

JavaScript 的格局日新月异,网站和应用的依赖关系也随之而变。

这篇文章适合那些大量使用 script 标签来加载 JS 的程序员,随着网页数目增多和项目规模的扩大,他们感觉到依赖管理变得越来越笨重。

如果想要深入了解每一个细节,同时想对 CommonJS 和 AMD 规范做比较的话,请参考 Axel Rauschmayer 的 Exploring ES6 book , 尤其是第 17 章。

什么是 JavaScript 模块?

JavaScript 模块允许我们把项目中的代码分散成一个个单独的文件,或者使用通过 npm 安装的开源模块。用模块化的方式写代码有助于(项目的)组织、维护、测试,以及最重要的依赖管理。

当我们编写 JavaScript 时,理想情况是保障每个模块都专注一件事并把这件事做好。这种分工可以让我们在需要某个模块时再去做相应的加载。模块化是是 npm 背后的核心原则。当需要某个特定的功能时,我们能安装相应的模块并加载到应用当中。

随着时间推移,我们发现那种大而全的框架变少了,看到更多的是 专注一件事并把这件事做好 的小型模块。

举个例子,大部分人都用过 jQuery。这个库包含了从 CSS 操作到 ajax 调用几乎全部的方法。现如今,很多人开始迁移到 React 这类库上,我们常常需要加载额外的模块来完成一些任务如 ajax 或路由。

这篇文章将会带你大致了解 npm 和 ES6 模块的使用。对于其它一些的包管理(如 Bower) 和模块加载工具(如 CommonJSAMD),已经有大量的文章和话题在讨论了。

不管你是做 Node 开发还是前端开发,我相信 ES6 模块和 npm 是未来的方向。如果你去看当下流行的开源项目,像 Reactlodash,你会发现他们都采用了 ES6 模块 + npm

当前的开发流程

很多 JavaScript 的开发流程是这样的:

  1. 找一个符合要求的插件或库然后从 GitHub 上下载。
  2. 通过 script 标签加载到网站。
  3. 用全局变量调用或以 jQuery 插件的方式调用。

这类开发流程这么多年来表现一直不错,除了这几个问题:

  1. 插件必须手动升级 - 很难及时得知(该插件)何时修复了严重的bug或是有哪些新功能可用。
  2. 混乱的源代码版本控制 - 所有依赖都要加入源代码,当库更新时会导致非常不愉快的结果(版本问题)。
  3. 基本没有依赖管理 - 很多脚本的功能是重复的,如果分成小模块则可以很轻松的实现共享。
  4. 代码污染和潜在的全局命名空间冲突。

编写模块化的 JavaScript 这种理念并不新鲜,不过随着 ES6 的到来和业界将 npm 作为 JavaScript 的首选包管理工具,我们看到大量的开发摒弃了从前的工作流程,迁移到使用 ES6 和 npm 的标准化流程上来。

等等,npm?那不是 Node 专用的吗?

很久以前,npm 是作为 Node.js 的包管理工具起步的,如今它已经进化为JavaScript和前端开发的包管理工具。现在,我们可以把库的安装过程简化为 2 个步骤:

  1. 从 npm 安装依赖,例如:
  2. 在当前文件中导入刚才的依赖,例如:

这套开发流程还需要很多的工作要做,同时关于模块的导入导出也有很多需要学习,现在让我们来深入了解一下吧。

模块背后的理念

我们使用导入和导出语句来在文件之间共享代码(变量、函数、数据、任何代码),而不是把所有代码加载到全局命名空间下。每一个模块导入需要的依赖,也可以为其它文件导出需要的代码。

让代码在浏览器运行还需要一个打包的步骤,我们会在文章的后面加以讨论,现在,让我们专注于 JavaScript 模块背后的核心理念。

创建自己的模块

假设我们正在构建一个在线购物的应用,需要一个文件存放所有的辅助函数。我们可以创建一个模块命名为 helpers.js ,文件包含一些辅助函数 - formatPrice(price)、 addTax(price) 和 discountPrice(price, percentage),还有一些关于该在线商城的变量。

我们的 helpers.js 文件看起来如下:

现在,每个文件都持有自己的本地函数和变量,只要没有明确地导出,它们绝不会渗透到其它文件的作用域中。在上面的例子里,我们可能不想让其它模块访问 taxRate 变量,但在模块内部确实需要这个变量。

我们怎么让其它模块访问到这些函数和变量呢?答案是导出它们。在 ES6 中有两种导出方式,命名导出和默认导出。由于需要让多个函数和 couponCodes 变量被访问到,我们使用命名导出。稍后我们会加以详述。

从模块导出代码,最简单直白的方式就是在行首加上 export 关键字,像这样:

我们也可以在最后再导出:

或者里一次性导出:

还有很多其它很便捷的导出方式,如果碰到有些情形无法满足你的工作需求,请查看 MDN 的文档。

默认导出

前面提到,从模块中有两种导出方式 - 命名或默认。上面的例子用了命名导出。如果要让其它模块导入这些出口,我们必须要知道我们希望导入的变量/函数的名称 - 接下来会有一个例子说明。使用命名导出的好处是你可以从一个模块中导出多项内容。

另一种导出方式是默认导出。当需要导出多个变量/函数时,可以用命名导出,当你的模块只需要导出一个变量/函数的时候,使用默认导出就行了。尽管你可以在一个模块中同时使用默认导出和命名导出,我还是建议你每个模块只采用一种方式。

默认导出的例子是一个单独的 StorePicker React 组件,或者是某个数组。例如,下面这个数组需要让其它组件访问到,我们可以用默认导出。

和上面一样,你可以在想要导出的函数到前面加上 export default 关键字。

导入自己创建的模块

既然我们已经把代码分成了小模块并且按需求导出了,现在可以向前一步,把这些模块导入到应用的其它部分了。

如果要导入的模块是代码库的一部分,我们使用 import 语句,然后指定文件相对于当前模块的路径 - 跟你平时在 HTML 中导入资源路径或 CSS 背景图是一样的。你会发现我们去掉了 .js 后缀,因为后缀不是必需的。

需要注意并不是导入一次模块,整个应用就能像全局变量一样去访问了。每当模块依赖其它模块时 - 比如我们上面的代码需要一个 lodash 方法 - 我们必须将它导入进来。如果我们有5个模块都需要同样的 lodash 函数,我们需要导入 5 次。这有助于保持作用域清晰,同时让模块更加轻便且可重复使用。

导入命名导出

我们最先导出的时我们的辅助模块。这里使用的是 命名导出,现在,有很多种方式将它们导入:

导入默认导出

如果你回想一下,我们还从 people.js 中导出了一个 first names 的数组,这是那个模块唯一需要导出的部分。

默认导出可以用任何名称导入 - 不需要知道导出的变量、函数、或类的名称。

从 npm 导入模块

我们使用的大量模块来自于 npm。不管你需要一个像 jQuery 这种完整库,还是 lodash 这种只有工具函数的库,又或是 superagent 这种提供 Ajax 请求的库,我们都可以用 npm 来安装。

一旦这些包存在在 node_modules/ 目录下了,就可把它们导入到我们的代码。默认情况下,Babel 会把 ES6 的导入语句编译成 CommonJS。所以,只要使用一个可以解析模块语法的打包工具(webpack 或者 browserify),你就可以玩转 node_modules/ 目录了。我们打导入语句只需要包含模块的名称就可以了。其它打包工具可能需要插件或配置才能从 node_modules/ 目录导入。

上面的代码能正常工作是因为 jQuery 是按 CommonJS 模式导出的, Babel 将 ES6 的 import 语句转译使其适配 jQuery 的 CommonJS 导出(语句)。

我们再试试 superagent。和 jQuery 一样,superagent 对整个库使用了CommonJS规范的默认导出,所以我们可以任意命名 - 一般命名成 request。

“精挑细选”——部分导入

我最喜欢 ES6 模块的一个特性就是,有大量的库允许你只选择你需要的代码。lodash 是个非常棒的工具库,里面有很多有用的 JavaScript 方法。

我们可以将整个库用 _(下划线) 变量导入,这是因为 lodash 将整个库作为一个主模块来导出(同样Babel 会将我们的 import 进行转译,效果等同于 lodash 使用了默认导出)

不过,更常见的是你只想导入一两个方法,而不是整个库。因为 lodash 已经将每个方法都作为一个模块导出了,所以我们可以选择只导入我们想要的部分! 同样Babel 的转译保证了这种做法的可行性。

确保模块是最新的

一些反对“微模块”编码的人们认为,这么做会导致 npm 中的库存在大量的相互依赖。

JavaScript 生态发展非常迅速,要让你的依赖维持最新状态非常困难。我们都知道不管是代码还是依赖都存在 bug、安全漏洞或者某些代码不再易用。 我们需要清楚的了解项目的各种不安全、被弃用的、过时的或无用的代码。

要解决这个问题,bitHound 公司提供了一项很棒的服务,这项服务能够持续监控你的代码,当你的依赖出现了任何错误都会及时向你报告,同时还会提供一个项目的综合统计评分。通过这项服务可以看出你的项目到底有多健壮,它对所有开源项目都是免费的。

bitHound 集成了 GitHub 和 BitBucket 并且推出了自动提交分析功能,这样当你的代码库发生变更时会通知 bitHound。一旦依赖库过期,你的 Slack 或 HipChat 就会收到通知,或收到一份包含详细信息的邮件。

bitHound 还包含了 Pull Requests 的分支状态 - 设置 通过/失败 标准,之后 bitHound 会将这些状态信息提交到 GitHub 或者 Bitbucket。

有个叫 npm-check-updates 的工具可以非常好地搭配 bitHound 工作。使用 npm install npm-check-updates -g 在你开发机器上全局安装,然后运行 ncu 命令,可以快速检查你的代码包是否需要升级。如果需要,你可以运行 ncu –upgradeAll 命令自动升级 package.json 里面的所有包。之后一定要运行 npm install 命令来从 NPM 上获取最新代码。

打包操作

因为浏览器现在还不支持 ES6 模块,我们需要一些工具让它们能正常工作。 JavaScript 打包工具可以把这些模块转译成一个单独的 JavaScript 文件,或者把应用程序的各个部分打包成多个文件。

最终我们不再需要打包工具,HTTP/2 加载时会自动请求所有的 import 语句。

这有一些流行的打包工具,大部分都使用 Babel 将 ES6 模块转译成 CommonJS。

  • Browserify 最初用来在浏览器中使用 nodejs 风格的代码。同样支持 ES6 模块
  • webpack 在 React 社区非常流行。不仅支持 ES6 ,还支持很多其它格式的模块代码。
  • Rollup 为 ES6 而生,但是source maps(一个记录代码转换前和转换后的位置信息文件)似乎有些问题 - 我会在一两个月后再看看。
  • JSPM 基于 npm SystemJS.
  • Ember CLI 为Ember用户提供的与 webpack 类似的简单命令行工具。使用了 Broccoli 引擎。

该怎么选呢?选最适合你的。我是 Browserify 和 webpack 的忠实粉丝,因为前者上手简单,后者容易与 React 集成。编写 ES6 模块的迷人之处在于你写的不是 Browserify 或 webpack 模块 - 你可以随时切换打包工具。有很多选用哪个工具的观点,快速搜索一下你会发现每个工具都有大量的论述。

如果你已经在执行任务时,使用了gulp, grunt, 或npm对现有的JavaScript和CSS文件进行操作,那么将模块引入工作流程非常简单。

实现打包非常简单 - 你可以将它作为一个 gulp 的子任务来运行,或者通过 webpack 配置、npm 脚本 或是直接使用命令行。

我创建了一个代码库,你可以通过几个简单模块的代码详细了解如何使用 webpack 和 Browserify。

导入非模块代码

如果你正在致力于将代码库模块化,但又很难一步做到,你可以简单的通过导入“文件名”来加载并执行文件中的代码。这不算 ES6,但它是打包工具的一个功能。

这个概念与连续执行多个 js 文件并无不同,除非你导入的代码作用域限制在导入的模块中。

需要全局变量的代码

有些库,比如说 jQuery 插件,不太适合 JavaScript 的模块化系统。整个 jQuery 插件系统都假设有一个叫window.jQuery的全局变量 ,每个插件可以附加在该变量之上。但是我们刚刚学过 ES6 模块没有全局变量。所有代码的作用域都局限于当前模块,除非你把一些代码明确地设置在window对象上。

要想解决这个问题,首先要问问自己是否真得需要这个插件,还是可以自己写一个。很多 JavaScript 插件系统已经重写并移除 jQuery 依赖,成为独立的 JavaScript 模块。

如果不是,你需要检查你的构建流程,看看能不能帮助解决问题。Browserify 有 Browserify Shim(用于解决不兼容Browserify或不兼容CommonJS的问题),webpack 也有相关文档。

陷阱

当导出一个函数时,不要在最后包含分号。很多打包工具仍然允许使用额外的分号,但是在函数声明后面去掉分号是最佳实践,这样当你切换其它打包工具时可以避免碰到一些奇葩的问题。

延伸阅读

希望这是一篇关于使用 npm 和 ES6 模块化不错的介绍。还有更多需要学习的内容,我认为,最好的学习方式就是在你的下一个项目中使用它。下面有一些些非常棒的学习资源,可以在你的前进道路上提供帮助。

Thanks + Updates

非常感谢 Stephen MargheimKent C. DoddsMike ChenBen BermanJuan Pablo Osorio Ospina 帮助校对并且提供了高质量的反馈意见。

如果你有任何意见、代码示例、技术升级或者说明,想加进来,请提交 pull request

2 9 收藏 1 评论

关于作者:段昕理

因为iPod而喜欢上苹果的一系列产品,非常认同他们追求极致的精神。工作之余,喜欢前端的开源项目,Github(https://github.com/sandywalker) 个人主页 · 我的文章 · 15 ·    

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部