【发布时间】：2012-03-01 04:23:09
【问题描述】：
用于 express.js 环境。有什么建议吗？
【问题讨论】：
-
对于多平台解决方案，您可以找到答案stackoverflow.com/a/57509175/11127383
标签： javascript node.js macos environment-variables
【发布时间】：2012-03-01 04:23:09
【问题描述】：
我没有看到任何地方明确提到的 Docker 解决方案；希望这可以帮助某人：
在 Dockerfile 中：
FROM node:16.11-alpine3.14 AS production
ARG NODE_ENV=production
ENV NODE_ENV=${NODE_ENV}
...
【讨论】：
您可以按如下环境运行，
NODE_ENV=production npm run start
【讨论】：
npm start --mode production
npm start --mode development
有 process.env.NODE_ENV = '生产'
【讨论】：
在运行您的应用程序之前，您可以在控制台中执行此操作，
export NODE_ENV=production
或者如果你在 Windows 中，你可以试试这个：
SET NODE_ENV=production
对于 PowerShell：
$env:NODE_ENV="production"
或者您可以像这样运行您的应用程序：
NODE_ENV=production node app.js
你也可以在你的js文件中设置：
process.env.NODE_ENV = 'production';
但我不建议在你的运行时文件中这样做，因为在你的服务器中打开 VIM 并将其更改为生产并不容易。您可以在您的目录中创建一个 config.json 文件，并且每次您的应用运行时，它都会从中读取并设置配置。
【讨论】：
-
这是个坏建议。从应用程序本身可靠地设置
process.env.NODE_ENV会很棘手。最好按照下面的 Daniel 链接正确设置您的环境变量。 -
我喜欢在每次运行应用程序时明确设置
NODE_ENV，如第二个示例 (NODE_ENV=production node app.js)。这样一来，如果您忘记将本地NODE_ENV设置回development，您就有可能免于将来的麻烦。 -
参考npmjs.com/package/cross-env 了解简单的跨平台解决方案。
cross-env NODE_ENV=production适用于 windows 和 linux/mac。 -
@Gleb
NODE_ENV=production forever app.js应该可以工作。 -
如果您正在使用设置文件并且知道自己在做什么，那么使用 process.env.NODE_ENV 没有任何问题
不必担心您是在 Windows、Mac 还是 Linux 上运行脚本，请安装 cross-env 包。然后您可以轻松地使用您的脚本，如下所示：
"scripts": {
"start-dev": "cross-env NODE_ENV=development nodemon --exec babel-node -- src/index.js",
"start-prod": "cross-env NODE_ENV=production nodemon --exec babel-node -- src/index.js"
}
给这个包的开发者的大量道具。
npm install --save-dev cross-env
【讨论】：
-
如果作为开发依赖安装它会如何工作？在生产环境中，应使用 --production 标志安装 npm 包，该标志不会安装跨环境，因为它是开发依赖项。
-
这个答案对我有帮助，但对每个人都没有帮助）
"tsc && NODE_ENV=production nodemon ..."- 工作。"NODE_ENV=production tsc && nodemon ..."- 不工作
Windows CMD -> set NODE_ENV=production
Windows Powershell -> $env:NODE_ENV="production"
MAC -> export NODE_ENV=production
【讨论】：
为了拥有多个环境，您需要之前的所有答案（NODE_ENV 参数并导出它），但我使用了一种非常简单的方法，无需安装任何东西。在您的 package.json 中，只需为您需要的每个环境添加一个脚本，如下所示：
...
"scripts": {
"start-dev": "export NODE_ENV=dev && ts-node-dev --respawn --transpileOnly ./src/app.ts",
"start-prod": "export NODE_ENV=prod && ts-node-dev --respawn --transpileOnly ./src/app.ts"
}
...
然后，要启动应用程序而不是使用npm start，请使用npm run script-prod。
在代码中你可以通过process.env.NODE_ENV访问当前环境。
瞧。
【讨论】：
-
NODE_ENV 应该是“开发”或“生产”，上面的第 3 方代码无法识别（尽管您可能正在查看 process.env）
对于 Windows Powershell 使用此命令
$env:NODE_ENV="production" ; node app.js
【讨论】：
如果您在应用程序中使用 webpack，您可以简单地设置它，使用 DefinePlugin...
因此，在您的 plugin 部分中，将 NODE_ENV 设置为 production：
plugins: [
new webpack.DefinePlugin({
'process.env.NODE_ENV': '"production"',
})
]
【讨论】：
在 OSX 上，我建议将 export NODE_ENV=development 添加到您的 ~/.bash_profile 和/或 ~/.bashrc 和/或 ~/.profile。
我个人将该条目添加到我的~/.bashrc，然后让~/.bash_profile ~/.profile 导入该文件的内容，因此它在不同环境中是一致的。
完成这些添加后，请务必重新启动终端以获取设置。
【讨论】：
export NODE_ENV=production不好解决，重启后消失。
如果您不想再担心该变量，请将其添加到此文件中：
/etc/environment
不要使用导出语法，只写（如果某些内容已经存在，则在新行中）：
NODE_ENV=production
重启后即可使用。您无需再在任何地方重新输入 export NODE_ENV=production 命令，只需将 node 与您想要的任何东西一起使用 - 永远，pm2...
对于 Heroku：
heroku config:set NODE_ENV="production"
这实际上是默认值。
【讨论】：
-
维护噩梦。没有 /etc 权限的盒子呢？
-
我个人使用
NODE_ENV=production gulp bundle-production-app来捆绑生产就绪脚本，在服务器中 NODE_ENV 在服务器环境中，而在开发机器中它不存在。在某些机器中，如果它没有设置并且您希望它设置总是，那将是一场噩梦。在某些情况下，您希望没有它，因此您不添加。无论如何，在做 UI 时，我会明确它是否处于开发模式，所以你永远不会怀疑它是打开还是关闭。如果 NODE_ENV 是 !== 生产，那么在你面前你就处于其他模式，所以根本没有噩梦。一切顺利，一切顺利。 -
+1 用于讨论如何使其持久化。我想知道有多少人只在当前会话中设置它，认为它会持续存在。 在重启之前呢？如果你想马上设置它，你应该把它放在
/etc/environment并运行export NODE_ENV=production吗？
这里还没有人提到.env？在你的应用根目录中创建一个.env 文件，然后require('dotenv').config() 并读取值。易于更改、易于阅读、跨平台。
【讨论】：
-
奇怪的是没有人提到它，我认为最好的解决方案。将环境名称与其余变量放在同一个文件中。
-
在 .env 文件中设置 NODE_ENV 不起作用。看到这个：github.com/motdotla/dotenv/issues/328
-
对我来说，在
.env文件中设置"mode": "production"有效。 -
还将 .env 添加到 .gitignore 以便在将代码推送到生产环境时不会覆盖 .env。即在环境中推送代码时，.env 应该保持不变。
如果您在 Windows 上。在正确的文件夹中打开你的 cmd 然后首先
set node_env={your env name here}
回车然后你可以启动你的节点
node app.js
它将从您的环境设置开始
【讨论】：
-
重启后不会消失吗？没有窗户，不能自己试试。
-
如果您询问的是节点重启否，它不会消失，直到您完全关闭命令提示符。但如果 Windows Server 重新启动，它就会消失。
-
谈论操作系统重启。这就是为什么我最好找到另一种方法来停止每次安装 Windows 更新或重新启动时一次又一次地思考这个问题。
在 package.json 中：
{
...
"scripts": {
"start": "NODE_ENV=production node ./app"
}
...
}
然后在终端运行：
npm start
【讨论】：
-
@WeDoTDD 你在说什么？这些脚本的使用方式与 makefile 的工作方式类似。使用它作为这个例子或者你提到的运行 gulp 是一个完全合理的用例。对于简单的任务，我现在什至不使用 gulp，而是在脚本中完成所有工作，让工作变得更快，我让 webpack 完成过去由 gulp 完成的工作。
-
因为您最终会在所有项目中使用不一致的脚本，这是维护的噩梦
-
@WTF - 在 package.json 中使用脚本是什么意思？这就是 scripts: 部分的重点，用于放置脚本！它完全有效并且消除了对 gulp 或 grunt 的需要。全部通过命令和 webpack 完成。
-
@WTF 使用脚本实际上大大提高了一致性。您可以设置一组标准命令以在多个项目中使用，这些命令可能不使用相同的底层构建脚本、库等。您至少可以尝试用事实和示例来支持您的观点。
-
将
NODE_ENV=production放入 package.json 没有多大意义。在开发中运行npm start将在生产中运行它。您可以像编写代码一样编写代码，因为您总是以这种方式运行它。我看到这样做的一个原因是强制其他模块（例如 Express）在生产模式下运行。如果环境变量从不改变，为什么还要使用它们？
Daniel 有一个绝妙的答案，这是正确部署（设置并忘记）过程的更好方法。
对于那些使用快递的人。 您可以使用 grunt-express-server，这也很棒。 https://www.npmjs.org/package/grunt-express-server
【讨论】：
heroku config:set NODE_ENV="production"
【讨论】：
-
啊这正是我所需要的。你真棒
-
NODE_ENV=production现在是 Heroku node.js 部署的默认值。 -
heroku 不是唯一部署的地方