如何在package.json中设置一些环境变量，以便与npm start类命令一起使用
以下是我目前在我的package.json中的内容：
1
2
3
4
5
6
7
8
| {
...
"scripts": {
"help":"tagove help",
"start":"tagove start"
}
...
} |
在这里，我想在开始脚本中设置环境变量(如NODE_ENV，同时仍然能够只使用一个命令npm start启动应用程序。
在脚本命令中设置环境变量：
1
2
3
4
5
6
| ...
"scripts": {
"start":"node app.js",
"test":"NODE_ENV=test mocha --reporter spec"
},
... |
然后在应用程序中使用process.env.NODE_ENV。
注意：这仅适用于Mac&Linux。对于Windows，请参阅注释。
- 有人想出了Windows的替代方案吗？
- @更好的NPM运行解决了跨平台的兼容性问题。但它的配置有点笨拙。
- @无穷大使用交叉环境和非常容易使用。
- @无限使用set NODE_ENV=test&& mocha --reporter spec-测试和故意测试之间没有空间。
- 谢谢@jamiepenney。我必须在开始工作之前移除空间。为什么会这样？`设置node_env=development&；(nexttask)
- @Tetradev记不起来了，对不起，我想是包括了固定通话的空间？
- Cross env在几秒钟内就为我工作了。只考虑在NPM测试中添加--save dev
- 不适用于npm run-script build。引发的错误"node_env"未被识别为内部或外部命令、可操作程序或批处理文件`
- "test":"NODE_ENV=test mocha --reporter spec"不能在Windows系统上工作。
- @Tetradev我认为你最终会把NODE_ENV设置为"测试"(注意空格)。如果你不想(或不能)使用引号，没有空格可以避免这种情况。
- 如果使用交叉环境，则不需要包括"&；&；"。示例：cross-env NODE_ENV=test karma start
- @杰米彭尼在什么环境下工作？
- @Infinity@jamie penney env NODE_ENV=test mocha --reporter spec将以本机跨平台方式使用声明的环境变量，但关键是它由NPM以临时和一次性的方式使用，仅用于NPM脚本的执行。(它没有设置或导出以供将来参考。)只要从NPM脚本运行命令，就没有问题。此外，这样做时必须删除"&；&；"。
- 如何在Windows中添加多个env变量？
- 如果要在脚本本身中使用env var，则需要预先准备$，例如，如果运行mode=prod npm run print，并且包中有一个脚本.json，名为print "print":"echo environment '$mode'"，它将打印environment 'prod'。
只需使用NPM包交叉环境。超级容易。适用于Windows、Linux和所有环境。请注意，您不会使用&；移动到下一个任务。您只需设置env，然后开始下一个任务。感谢@mikekidder在其中一条评论中提出的建议。
来自文档：
1
2
3
4
5
| {
"scripts": {
"build":"cross-env NODE_ENV=production OTHERFLAG=myValue webpack --config build/webpack.config.js"
}
} |
注意，如果要设置多个全局变量，只需连续地声明它们，然后执行命令。
最后，执行(使用spawn)的命令是：
1
| webpack --config build/webpack.config.js |
NODE_ENV环境变量将由cross env设置。
- 三个反斜杠可用于转义所需的引号："test":"cross-env TS_NODE_COMPILER_OPTIONS='{\\"module\\":\\"commonjs\\"}' mocha"。
- 最佳解决方案，因为跨平台。
我只想在这里为将来的节点探索者添加我的2美分。在我的Ubuntu 14.04中，NODE_ENV=test不起作用，我不得不使用export NODE_ENV=test，之后NODE_ENV=test也开始起作用，很奇怪。
在Windows上，正如前面所说，您必须使用set NODE_ENV=test，但对于跨平台解决方案，cross env库似乎没有做到这一点，您是否真的需要一个库来做到这一点：
1
| export NODE_ENV=test || set NODE_ENV=test&& yadda yadda |
垂直杆是必需的，否则窗户会撞到无法识别的export NODE_ENV命令：d.dunno关于尾随空格，但只是为了确保我也删除了它们。
- 你用过&&吗？NODE_ENV=test yadda是指"运行yadda"，在yadda的环境变量中设置NODE_ENV。NODE_ENV=test && yadda是指"在当地环境中设置NODE_ENV但不导出，然后运行yadda"，NODE_ENV=test yadda是首选的方法。
- 很抱歉，我的stackoverflow帐户有一段时间没查到了。但基本上，愚蠢的窗户不能使用NODE_ENV=test && npm run test或类似的东西。我在testhelper.js文件中使用process.env["NODE_ENV"] ="testing";提出了一个更好的解决方案。
- @teemuk也只是为了增加我的2美分，当您使用&&运行命令时，您丢失了环境变量，在不导出的情况下设置环境变量只对当前命令有效(这不是什么)。使用env变量运行命令而不导出u do:NODE_ENV=test npm run test。最后，它在您导出后工作的原因是，因为UR变量现在在会话中可用(导出)，没有导出的节点_env不做任何事情。
突然我发现actionhero使用了以下代码，通过在start-script命令选项中传递--NODE_ENV=production，解决了我的问题。
1
2
3
4
5
| if(argv['NODE_ENV'] != null){
api.env = argv['NODE_ENV'];
} else if(process.env.NODE_ENV != null){
api.env = process.env.NODE_ENV;
} |
我真的很高兴能接受其他人的回答，他们更了解如何在package.json或init脚本中设置环境变量，或者类似于其他人引导应用程序的方法。
在Windows上尝试此操作，方法是替换YOURENV：
1
2
3
4
5
6
7
8
| {
...
"scripts": {
"help":"set NODE_ENV=YOURENV&& tagove help",
"start":"set NODE_ENV=YOURENV&& tagove start"
}
...
} |
因为我经常发现自己在处理多个环境变量，所以将它们保存在单独的.env文件中(确保从源代码管理中忽略这一点)非常有用。
1
2
| VAR_A=Hello World
VAR_B=format the .env file like this with new vars separated by a line break |
然后在您的脚本命令之前预先准备好export $(cat .env | xargs) &&。
例子：
1
2
3
4
5
6
7
8
9
10
| {
...
"scripts": {
...
"start":"export $(cat .env | xargs) && echo do your thing here",
"env":"export $(cat .env | xargs) && env",
"env-windows":"export $(cat .env | xargs) && set"
}
...
} |
对于测试，您可以通过运行npm run env或npm run env-windows来查看env变量。
虽然我没有直接回答这个问题，但我想在其他答案的基础上分享一个想法。从我所获得的信息来看，每一个都将提供一定程度的复杂性，以实现跨平台的独立性。
在我的场景中，我最初希望设置一个变量来控制是否使用JWT身份验证来保护服务器(用于开发目的)。
在阅读了答案之后，我决定创建两个不同的文件，分别打开和关闭身份验证。
1
2
3
4
| "scripts": {
"dev":"nodemon --debug index_auth.js",
"devna":"nodemon --debug index_no_auth.js",
} |
这些文件只是调用原始index.js文件(我将其重命名为appbootstrapper.js)的包装器：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| //index_no_auth.js authentication turned off
const bootstrapper = require('./appbootstrapper');
bootstrapper(false);
//index_auth.js authentication turned on
const bootstrapper = require('./appbootstrapper');
bootstrapper(true);
class AppBootStrapper {
init(useauth) {
//real initialization
}
} |
也许这能帮助别人
1
2
3
4
5
6
7
| {
...
"scripts": {
"start":"ENV NODE_ENV=production someapp --options"
}
...
} |
不应在package.json中设置env变量。actionHero使用NODE_ENV允许您更改从./config中的文件加载的配置选项。查看redis配置文件，查看node_env如何用于更改NODE_ENV=test中的数据库选项。
如果您想使用其他env变量来设置内容(可能是HTTP端口)，您仍然不需要更改package.json中的任何内容。例如，如果在env中设置PORT=1234并希望将其用作NODE_ENV=production中的HTTP端口，只需在相关配置文件中引用它，即：
1
2
3
4
5
6
7
8
9
10
| # in config/servers/web.js
exports.production = {
servers: {
web: function(api){
return {
port: process.env.PORT
}
}
}
} |
- 伟大的。我想你没读过我的问题……我的问题是如何设置节点环境，而不是它的用途。
- 我想用一个命令行设置node_env和other。
- 如果要设置多个环境属性，则不在npm start命令中进行设置。使用上面的代码片段，如果您想使用env端口运行服务器，它应该是：export PORT=1234; npm start。您可以根据需要附加任意多个env声明，但它们不属于package.json文件。如果您担心它们是否存在，那么应该在配置文件中使用缺省值：port: process.env.PORT || 8080。
- 也许另一种解释这一点的方法是，节点env(和其他环境变量)是环境的一部分(因此得名)。它们通常是运行应用程序的服务器的属性，而不是应用程序的属性。您可以通过执行的命令手动设置它们，例如：NODE_ENV=test npm start或由shell设置它们。
- 我不同意。在部署应用程序时，对每个环境使用./config将限制您使用静态环境。这是一种过时的理念，它不允许您在需要时启动新类型的环境。也就是说，对于您想要的每个新环境，都必须添加一个.config。当您的技术栈需要更大的灵活性时，在运行时设置环境变量是一个更好的选择。我认为您的./config对于设置环境的"类型"是很好的，但是如果您可以在运行时定义DSN字符串和API端点之类的东西，那么您的应用程序将更加灵活。
- @jessegreathouse-我有一个node.js应用程序，我需要在运行时设置环境变量-我要在哪个文件中设置它们？
这将在Windows控制台中工作：
1
2
3
4
| "scripts": {
"aaa":"set TMP=test && npm run bbb",
"bbb":"echo %TMP%"
} |
npm run aaa
输出：test
有关详细信息，请参阅此答案。
- 应该是set TMP=test&& npm run bbb。&&之前的空格也可以作为NODE_ENV字符串的一部分。