不少人都曾经在 npm 上发布过自己开发的 JavaScript 模块，而在使用一些模块的过程中，我经常产生“这个模块很有用，但如果能 xxx 就更好了”的想法。所以，本文将站在模块使用者的角度总结一下，如何能让模块变得更好用。

提供 ES6 模块的入口

webpack 和 rollup 都支持对 ES6 模块做一些静态优化（例如 Tree Shaking 和 Scope Hoisting），它们都会优先读取 package.json 中的 module 字段作为 ES6 模块的入口，若没有 module 才会读取 main 字段作为 CommonJS 模块的入口。通常的做法是：使用 ES6 语法编写源码，然后用模块打包工具结合语法转换工具生成 CommonJS 模块和 ES6 模块，这样就可以同时提供 main 和 module 字段了。

提供 TypeScript 的类型声明文件

如果你的用户使用了 TypeScript 但你的模块没有提供声明文件，他们就不得不在项目中添加一段代码避免 TypeScript 的编译错误；另外，这样做并不只是对使用 TypeScript 的用户友好，因为大部分代码编辑器（Webstorm、VS Code 等）都能识别 TypeScript 的类型声明，它们可以据此提供更精准的代码提示并在用户传入错误的参数个数或类型时给出提示。

最好的做法是使用 TypeScript 编写你的模块，编译时会自动生成类型声明。除此之外，你也可以参照文档手动维护一份声明文件。你可以在你的模块根目录下添加 index.d.ts 文件，或者在 package.json 中声明 typings 字段提供声明文件的位置。

让模块同时在 Node.js 与浏览器中运行

你可以通过检测是否有名为 window 的全局变量（例如 !!typeof window）来判断模块当前是运行在 Node.js 还是浏览器中，然后使用不同的方式实现你的功能。

这种方法比较常见，但如果用户使用了模块打包工具，这样做会导致 Node.js 与浏览器的实现方式都会被包含在最终的输出文件中。针对这个问题，开源社区提出了在 package.json 中添加 browser 字段的提议，目前 webpack 和 rollup 都已经支持这个字段了。

browser 字段有两种使用方式：

给 browser 字段提供一个文件路径作为在浏览器端使用时的模块入口，但需要注意的是，打包工具会优先使用 browser 字段指定的文件路径作为模块入口，所以你的 module 字段会被忽略，这会导致打包工具不会优化你的代码。详细信息请参考这个问题。

如果你只想替换其中一些文件，你可以声明一个对象。

举个例子，假设你的模块里有两个文件：http.js 和 xhr.js，第一个文件使用 Node.js 中的 http 模块发起请求，另一个使用浏览器中的 XMLHTTPRequest 实现了同样的功能。为了使用适当的文件，你的模块代码中应该始终 require(‘./path/to/http.js')，并在 package.json 中声明：

{
 "browser": {

 "./path/to/http.js": "./path/to/xhr.js"
 }
}

这样一来，当你的模块在打包工具中使用时，打包工具只会将 xhr.js 的代码包含在最终的输出文件中。

使用各种服务武装你的项目

大部分 JavaScript 项目都是开源的，而开源社区也提供了很多针对开源项目的免费服务，它们可以给你的项目提供更有力的帮助，这里列举几个比较常用的。

一个项目最常使用的服务就是持续集成了。持续集成服务能将测试、代码风格检测、打包等任务放在服务器上，并在你提交代码时自动运行，常用的有 Travis CI、CircleCI 和 AppVeyor。Travis CI 对开源项目免费，提供 Linux 与 OS X 运行环境；CircleCI 对开源与私有项目都免费，但每个月有 1500 分钟的运行时间；AppVeyor 提供 Windows 运行环境，同样对开源项目免费。

运行完测试之后，你还可以将测试覆盖率上传到 Coveralls。这个服务能让你在线浏览代码的测试覆盖情况。

如果你想让你的模块在各个版本的各种浏览器、平台下得到充分的测试，你还可以使用 Sauce Labs 和 BrowserStack，它们都是对开源项目免费的，但需要发邮件申请。

最后，Shields IO 提供了各种图标，这些图标能为你的项目提供很多额外信息，包括但不限于 npm 版本号、下载量、测试通过状态、测试覆盖率、文件大小、依赖是否过期等。