我应该忽略测试吗? [英] Should I .npmignore my tests?

问题描述

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

测试?像.travis.yml，.jshintrc这样的东西?在运行模块时不需要什么(自述文件除外)?

Tests? Stuff like .travis.yml, .jshintrc? Anything that isn't needed when running the module (except the readme)?

我对此没有任何指导.

推荐答案

正如您可能发现的那样，NPM并没有具体说明应该放入的内容，而是有一个

As you probably found, NPM doesn't really state specifically what should go in there, rather they have a list of ignored-by-default files. Many people don't even use it as everything in your .gitignore is ignored in npm by default if .npmignore doesn't exist. Additionally, many files are already ignored by default regardless of settings and some files are always excluded from being ignored, as outlined in the link above.

应该永远存在的东西并不多，因为它基本上是.gitignore的子集，但是根据我使用节点5年的经验，这是我想出的.

There is not much official on what always should be there because it is basically a subset of .gitignore, but from what I gather from using node for 5-ish years, here's what I've come up with.

注意:通过 production ，是指任何时候有人使用您的模块而不是在模块本身上进行开发.

Note: By production I mean any time where your module is used by someone and not to develop on the module itself.

• 优点:如果您使用的是可交叉编译为JavaScript的语言，则可以在发布前进行预编译，并且不将.coffee文件包含在程序包中，但可以继续在git存储库中进行跟踪. /li>

• Pros: If you are using a language that cross-compiles into JavaScript, you can precompile before release and not include .coffee files in your package but keep tracking them in your git repository.

• 优点:使用诸如node-gyp之类的东西的人可能会在构建期间生成目标文件，而这些文件永远都不会进入软件包.
• 缺点:无论如何，这始终应放在.gitignore中.如果您已经在使用.npmignore文件，则必须将它们放在此处，因为从npm的角度来看，它会覆盖.gitignore.

• Pros: People using things like node-gyp might have object files that get generated during a build that never should go into the package.
• Cons: This should always go into the .gitignore anyway. You must place these things inside here if you are using a .npmignore file already as it overrides .gitignore from npm's point of view.

• 优点:生产代码中的行李减少.
• 缺点:您无法在实时环境中运行测试，这很少有系统特定的故障，例如，节点运行的版本过旧会导致测试失败.

• Pros: Less baggage in your production code.
• Cons: You cannot run tests on live environments in the slim chance there is a system-specific failure, such as an out of date version of node running that causes a test to fail.

• 优点:同样，减少了行李负担.使用，测试或查看代码不需要诸如.travis.yml之类的东西.

• Pros: Again, less baggage. Things such as .travis.yml are not required for using, testing, or viewing the code.

• 优点:减少行李负担.在思想流派中有些人存在，如果您不能在自述文件中至少表达最少的可行功能，则您的模块太大.
• 缺点:人们无法在自己的文件系统上看到详尽的文档和代码示例.他们将必须访问存储库(这也需要Internet连接).

• Pros: Less baggage. Some people exist in the school-of-thought where if you cannot express at least minimum viable functionality in your Readme, your module is too big.
• Cons: People cannot see exhaustive documentation and code examples on their own file system. They would have to visit the repository (which also requires an internet connection).

• 优点:您当然不需要使用CNAME文件或占位符index.html乱丢发行版，如果您使用的模块也可以兼作gh-pages信息库

• Pros: You certainly don't need to litter your releases with CNAME files or placeholder index.htmls if you use your module serves double-duty as a gh-pages repository as well.

• 优点:如果您决定在发布之前构建依赖项，则不需要最终用户安装bower，然后再安装更多东西.我个人将这些东西放在包装中.当我执行npm install时，我应该只依赖npm，而不能使用其他外部资源.

• Pros: If you decide to build in your dependencies prior to release, you don't need the end-user to install bower then install more things with that. I would, personally, keep that stuff in the package. When I do an npm install, I should only be relying on npm and no other external sources.

基本上，如果您希望将某些东西保留在npm软件包中，但又不想将其保留在npm存储库中，则应该使用它.这不是一长串的物品，但是npm宁愿内置功能而不是让人们将不相关的对象卡在包装中.

Basically, you should ever use it if there is something you wish to keep out of your npm package but not out of your npm repository. It's not a long list of items, but npm would rather build in the functionality than having people stuck with irrelevant objects in their package.

这篇关于我应该忽略测试吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！