我应该 .npmignore 我的测试吗？

Posted 2023-02-22

【中文标题】我应该 .npmignore 我的测试吗？

【英文标题】：Should I .npmignore my tests?

【发布时间】：2014-09-27 06:58:32

【问题描述】：

我应该在.npmignore 中输入什么？

测试？ .travis.yml、.jshintrc 之类的东西？运行模块时不需要的任何东西（自述文件除外）？

我找不到这方面的任何指导。

【问题讨论】：

当有人打电话给npm install yourlibrary时应该忽略所有不需要的东西，例如.travis.yml和.jshintrc

真的吗？甚至是自述文件？这是官方推荐的吗？

无论.npmignore 或"files" (docs.npmjs.com/files/package.json#files)，都会自动包含自述文件。

【参考方案1】：

澄清一下，只要有人这样做npm install your-library，npm 将下载包中包含的所有源文件。 your-library包源代码中.npmignore文件中包含的文件在发布lib时会被排除，所以your-library的用户不会下载。

知道安装你的库的人只需要运行你的库，其他任何东西都不需要。

例如，当有人安装一个库时，他/她可能并不关心您的.travis.yml 或您的.jshintrc 文件，甚至是一些图像、Grunt 文件、文档等。

.npmignore 可以让你的 npm 包文件更少，下载速度更快

【讨论】：

这里的观点很好，但要澄清一下：.npmignore 不会直接影响 下载的内容，它会影响 npm publish 时进入包的内容 并上传。这会间接创建较小的文件以供下载。

【参考方案2】：

正如您可能发现的那样，NPM 并没有具体说明应该在其中放入什么，而是有一个 list of ignored-by-default files。许多人甚至不使用它，因为如果.npmignore 不存在，默认情况下npm 中会忽略.gitignore 中的所有内容。此外，无论设置如何，许多文件都已默认被忽略，并且某些文件始终被排除在忽略之外，如上面的链接中所述。

官方并没有太多关于应该始终存在的内容，因为它基本上是 .gitignore 的一个子集，但从我使用 node 5 年收集到的信息来看，这就是我想出的。

注意：生产我的意思是任何时候你的模块被某人使用而不是在模块本身上开发。

---

预发布的交叉编译源

优点

：如果您使用的是交叉编译成 javascript 的语言，您可以在发布前进行预编译，并且不在您的包中包含 .coffee 文件，而是在您的 git 存储库中继续跟踪它们。

构建文件剩余部分

优点

：使用 node-gyp 之类的东西的人可能会拥有在构建过程中生成的目标文件，这些文件永远不应该放入包中。

缺点

：无论如何，这应该始终进入.gitignore。如果您已经在使用 .npmignore 文件，则必须将这些内容放在此处，因为从 npm 的角度来看，它会覆盖 .gitignore。

测试

优点

：生产代码中的包袱更少。

缺点

：您无法在实时环境中运行测试，因为系统特定故障的可能性很小，例如运行的节点版本过时导致测试失败。

持续集成设置/元文件

优点

：同样，行李更少。使用、测试或查看代码不需要 .travis.yml 等内容。

非自述文件和代码示例

优点

：行李更少。有些人认为如果你不能在自述文件中表达至少最小可行的功能，你的模块就太大了。

缺点

：人们无法在自己的文件系统上查看详尽的文档和代码示例。他们必须访问存储库（这也需要互联网连接）。

Github 页面对象

优点

：如果您使用您的模块作为gh-pages 存储库，那么您当然不需要在您的版本中乱扔CNAME 文件或占位符index.htmls。李>

bower.json 和朋友

优点

：如果您决定在发布之前构建依赖项，则不需要最终用户安装 bower，然后再安装更多的东西。就个人而言，我会将这些东西保存在包装中。当我执行npm install 时，我应该只依赖 npm 而没有其他外部资源。

---

基本上，如果您希望将某些内容保留在您的 npm 包之外，但又不想保留在您的 npm 存储库之外，那么您应该永远使用它。这不是一个很长的项目列表，但 npm 宁愿构建功能，也不愿让人们在他们的包中卡住不相关的对象。

【讨论】：

没有办法从 package.json 文件中删除不可用的脚本。例如。测试脚本？删除所有内容但将脚本保留在文件中，我觉得有点乱......

不，没有。你可以从 package.json 中省略它们，因为它主要用于 NPM，如果你只运行测试，你可以通过原始命令访问它们来运行它们。

【参考方案3】：

我同意lante's short and syntetic answer 和SamT's big answer：

不应将测试包含在包中。 您的包应该只包含生产运行时文件。 这将使您的软件包更简单、更快速地下载。

我对这些答案的贡献：

.npmignore是实现包文件选择的黑名单方式。但以更实用的方式，您可以在 package.json 中whitelist 需要包含在您的包using the files field 中的文件：

  "files": [
    "lib/",
    "index.js"
  ]

我认为这更简单，面向未来并且具有更好的语义；）

【讨论】：

...更不用说更容易记住和更不容易使用（如果你像我一样健忘的话）。感谢您的提示，这很棒。

我喜欢这种方法。

我认为你甚至可以省略“index.js”，假设它是你 package.json 中的“主”文件 :)

忽略图像和不必要的文档是可以的。但是忽略测试可能不是一个好主意。下载一些额外的 KB 不会花费太多时间，并且在所有 node_modules 中执行递归 npm test 可以提示您是否在特定环境中工作有所不同。

@NicolásFantone files 属性也接受 glob 模式。所以我们可以忽略测试文件而不创建.npmignore。 files: ["lib", "!lib/**/*.test.js"]。 :)

【参考方案4】：

不要包含您的测试。测试通常是实际代码库大小的 5 倍。只要你的测试在 Github 等上就足够了。

但是你绝对应该做的是测试你的 NPM 包以它的发布格式。创建一些驻留在实际代码库中但不属于测试套件的冒烟测试。

您可以在此处阅读有关在打包后测试您的包的信息： https://github.com/ORESoftware/r2g

How to test an `npm publish` result, without actually publishing to NPM?