关于package.json中的“scripts”键

Question

任何人都可以解释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"
 }

Answer 1

scripts键提供了一个方便的位置，可以在您已经强制使用的package.json定义项目特定的自动化脚本。 这有助于开发人员只需输入简单的内容，例如npm run cover或npm run deploy ，并启动可能复杂的一系列步骤（具有非常特定的文件位置或程序参数）。 这可以避免键入长命令行，并避免错误。 例如，我的一个项目包括以下命令：

"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"
}

我可以快速运行测试，覆盖测试，或只需几句话就可以部署到云主机，而且不必记住详细的命令行选项或文件位置。

但要注意。 JavaScript / node.js社区中存在很多关于定义这种自动化的“最佳”或“正确”位置的争议。

许多开发人员更喜欢将自动化转移到单独的“任务运行者”/“构建系统”，例如gulp ， grunt ，甚至是好的Unix make 。 对于这些项目， scripts标记将为空或几乎为空。 （ npm init默认生成至少一个键，用于test 。）而是需要查看他们的gulpfile.js ， Gruntfile或Makefile 。

其他开发人员拒绝了成为构建系统机制和/或分离构建配置的想法。 他们通常喜欢直接在package.json “一些简单的脚本”并将其称为一天。

根据我的经验，“一些简单的命令”是一个很好的目标，但脚本的复杂性很快就会超过它。 在具有许多不同资产和资产类型的大型项目中尤其如此，需要进行实时重建或实时重新加载，或者具有多个部署选项。 我通常最终会gulp这个繁重的东西，但也许一些真正简洁的脚本仍然存在于package.json 。 “你的旅费可能会改变。”

Answer 2

请参阅此内容，它将为您提供package.json中更好的创意脚本 。