本文来自国外技术博客RisingStack。感兴趣的同学可以点击查看原文。相信npminstall是npm-cli最常用的功能，但其实它还有很多其他值得挖掘的地方。在本文中，您将了解npm如何在应用程序开发的整个生命周期中帮助您更好地开发，包括从新建、到开发、到发布和上线。0.npm的基本使用在进入今天的话题之前，我们先来回顾一下npm的一些命令，比如如何判断你的npm版本，你可以使用哪些命令等等。0.1npm版本要查看现有的npm版本，在命令行工具中运行以下命令：$npm--version但是npm实际上可以告诉你更多关于版本的信息，比如每个包的当前版本，Node的版本.js、OpenSSL版本、V8版本等，如下：$npmversion{bleak:'1.0.4',npm:'2.15.0',ares:'1.10.1-DEV',http_parser:'2.5.2'，icu：'56.1'，模块：'46'，节点：'4.4.2'，openssl：'1.0.2g'，uv：'1.8.0'，v8：'4.5.103.35'，zlib：'1.2.8'}0.2npmhelp和很多cli工具一样，npm也内置了一个非常好用的帮助功能，可以让你随时查看各种命令的描述和总结，其实就是linux的man-pages。例如：$npmhelptestNAMEnpm-test-测试包SYNOPSISnpmtest[--]别名：t,tstDESCRIPTION如果提供的话，这将运行包的“测试”脚本。要将测试作为安装条件运行，请将npat配置设置为true。1.使用npminit来创建你的项目当开始一个新项目时，npminit可以通过交互式创建一个package.json文件来帮助你很多。这将提示有关项目名称或描述的问题。但是，有一个更快的解决方案！在创建项目的时候，npminit的好处是可以交互式的给你创建一个package.json文件，它会弹出一个问题让你填写项目的名称和描述等等。但是实际上是有的更简化的方法：$npminit--yes如果你使用npminit--yes，它不会问你如何创建它，只用默认配置创建一个package.json。当然也可以设置这个默认配置：npmconfigsetinit.author.nameYOUR_NAMEnpmconfigsetinit.author.emailYOUR_EMAIL2.找到npm包考虑到npm里面有上万个模块供你选择从，你必须找到合适的。包裹非常难。我们团队的经历是这样的。在最近的Node.js问卷调查中，很多开发者也告诉我们，找不到合适的包是一件非常令人沮丧的事情。那么现在我们就试着找一个可以发送HTTP请求的模块吧~npms.io可以很好的帮助我们。对每个包的质量、流行度、可维护性等指标进行量化展示。具体来说，这些指标包括：是否使用过时的依赖包，是否有代码检查配置，是否经过测试，最新版本发布时间等。3.了解你选择的包选择模块后想要使用（在本例中，我们选择了request模块），首先要查看它的文档，看看存在哪些问题，从而充分了解我们想要在应用中使用的模块。我希望你记住，你使用的npm包越多，你可能遇到的不可靠或危险的包就越多。要了解有关npm相关安全风险的更多信息，请阅读我们编写的指南文档。如果想进入包的主页，可以执行以下命令：$npmhomerequest要查看存在的问题或公共路线图，执行以下命令：$npmbugsrequest另外，要查看包仓库，执行以下命令：$npmreporequest4.保存依赖当你找到你要在你的项目中使用的包时，下一步就是安装并保存它。最常见的方式是使用npminstallrequest（译注：其中request为包名）。如果你仍然想自动将这个包添加到package.json，你可以这样做：$npminstallrequest--savenpm将保存你的依赖项并添加一个^前缀。这个前缀意味着下次使用npminstall时，会自动安装这个大版本下的这个包的最新版本。如果你想修改这个功能，你可以：$npmconfigsetsave-prefix='~'如果你只想保存当前版本，你可以：$npmconfigsetsave-exacttrue5。可以像上一节那样锁定依赖，保存依赖的版本号在package.json中指定。但是大多数npm模块作者并不会这样做，因为他们希望自动获得补丁和新功能。但是在生产环境中，如果不指定保存依赖的版本号，就会出现问题。因为如果作者在你开发的时候发布了新的版本，有可能本地和生产环境使用的依赖版本不一样。这时候如果新版本有bug，就会影响生产环境。要解决此问题，您可以使用npmshrinkwrap。它会生成一个npm-shrinkwrap.json文件，这个文件不仅记录了当前环境使用的模块的精确版本号，还记录了这些模块的其他依赖的版本等等。一旦这个文件在项目中，npminstall将使用它来复制一个精确的依赖树。6.查找过时的依赖npm提供了一个内置的工具方法来查看过时的依赖：npmoutdated。$npmoutdatedconventional-changelog0.5.30.5.31.1.0@risingstack/docker-nodeeslint-config-standard4.4.04.4.06.0.1@risingstack/docker-nodeeslint-plugin-standard1.3.11.3。12.0.0@risingstack/docker-noderimraf2.5.12.5.12.5.4@risingstack/docker-node当你维护很多项目时，保持每个项目中的依赖关系是最新的非常重要痛苦的事。要自动执行此任务，您可以选择Greenkeeper，它会在有依赖项更新时自动为您的仓库发送拉取请求。7.生产环境没有devDependencies。devDependencies被称为开发环境依赖项是有原因的。您在生产环境中不需要它们。在生产环境中不使用这些devDependencies可以让你的线上代码包更小更安全，因为多一个依赖就意味着多一个安全风险。如果你只需要安装生产环境依赖，运行：$npminstall--production或者，你可以将NODE_ENV变量设置为生产环境：$NODE_ENV=productionnpminstall8。确保你的项目和token的安全如果你在开发系统用户时登录Linux，你的npmtoken会被保存在.npmrc文件中。有时候这个文件会不小心上传到github。目前，如果你在github上搜索.npmrc文件，你可以找到成千上万的文件，其中很多包含token。如果你自己的仓库里也有.xxx文件，赶快查看你的证书是否上传好了！另一个潜在的安全风险是某些文件被意外发布到npm。一般而言，npm会参考.gitignore文件来决定上传哪些文件。但是你也可以添加一个.npmignore文件来覆盖.gitignore。9.开发包在本地开发包的时候，大家一般都是先在自己的项目上实践一下再发布。这时候npmlink就可以派上用场了。npmlink的作用是会在全局目录下创建一个symlink（符号链接），指向npmlink运行的包。您还可以在别处运行npmlinkpackage-name，这将在全局安装的package-name和当前项目的/node_modules之间创建一个符号链接。你可以这样练习！#创建指向全局文件夹/projects/request的符号链接$npmlink#将请求链接到当前node_modules/projects/my-server$npmlinkrequest#运行此项目后，require('request')#将包含该模块来自项目/请求
