关于package.json中的“脚本”键

任何人都可以解释package.json文件中“脚本”键的用途是什么。

在学习Angular 2时,我在package.json文件的脚本下面碰到了,不知道这个键的用法是什么。

"scripts": { "postinstall": "npm run typings install", "tsc": "tsc", "tsc:w": "tsc -w", "start": "concurrent \"node ./bin/www\" \"npm run tsc:w\"", "typings" : "typings" } 

scripts键提供了一个方便的地方,在你的必需的package.json定义项目特定的自动化脚本。 这有助于开发人员简单地input一些简单的东西,比如npm run cover或者npm run deploy并且有一系列可能复杂的步骤(非常具体的文件位置或者程序参数)。 这样可以避免input长命令行,避免错误。 例如,我的一个项目包括这些命令:

 "scripts": { "cover": "cd source/js/jutil && istanbul cover _mocha -- -R spec && open coverage/lcov-report/jutil/index.html", "test": "cd source/js/jutil && mocha", "deploy": "(git diff --quiet --exit-code --cached || git commit -a -m 'deploy') && git push heroku master && heroku open", "start": "gulp start" } 

我可以快速运行一个testing,一个覆盖testing,或者用几个字就可以部署到云主机,而不必记住详细的命令行选项或文件位置。

小心,但是。 JavaScript / node.js社区有很多关于定义这种自动化的“最佳”或“正确”地方的争议。

许多开发人员更喜欢将自动化转移到单独的“任务执行者”/“构build系统”,如gulp , grunt ,甚至是unix的make 。 对于这些项目, scripts标记将是空的或几乎如此。 (默认情况下npm init至less会生成一个单独的键,用于test 。)相反,您需要查看它们的gulpfile.jsGruntfileMakefile

其他开发者已经拒绝成为构build系统机制和/或分离构buildconfiguration的想法。 他们通常更愿意把“简单的几个脚本”直接放在package.json ,然后每天调用它。

根据我的经验,“一些简单的命令”是一个伟大的目标,但是脚本复杂性可能会很快超过它。 在具有许多不同资产和资产types的较大项目中,尤其需要进行实时重build或实时重新加载,或者具有多个部署选项。 我通常最终会gulp做这个事情,但是也许还有一些脚本可以真正简洁的expression出来,这些脚本仍然在package.json 。 “你的旅费可能会改变。”

参考这个,它会给你一个更好的想法脚本在package.json 。