I would like to use different credentials in my Netlify functions depending on my NODE_ENV variable. I have a Gatsby project and when I run netlify dev Gatsby sets NODE_ENV === development and gatsby develop command sets it to production.
Please have a look at Auth.js file https://github.com/iamskok/gatsby-dev-blog-starter/tree/feature/github-comments/.netlify/functions
Netlify functions have to use the same ENV variables as Gatsby does.
NODE_ENV is a tricky one to use because so many web tools use it toggle on/off production optimizations - its meaning has become somewhat overloaded. Take for example deploying to Netlify you always want to see an optimised prod build, even when deploying to a non-prod develop env, so NODE_ENV should always be "production" there.
So perhaps the answer is to setup a new env var APP_ENV (or whatever) that you can freely change in Netlify/Gatsby to properly indicate the current env (dev vs. staging vs. prod) and leave NODE_ENV for the tools to manage themselves.
They talk about it a bit in the Gatsby docs here:
https://www.gatsbyjs.org/docs/environment-variables/#additional-environments-staging-test-etc
Related
I'm using Vite framework to build my frontend application.
I would like to be able to build a version once, let's say 1.0 and then run it in dev env (with dev variables), then in production (with prod variables). As I do with Java apps for example.
This is quite important because I don't want to "build for prod" once my tests in dev are ok, taking the risk of building something slightly different from dev (dependencies, or even commits).
I know that node frontend projects are simply plain JS files once the application is built, so I don't think reading an env variable would be possible.
Any idea ?
I'm developing an application with my team with Firebase, and I want to deploy my app both in development and production environments.
To achieve this, I have done several things. (Details are below)
But NODE_ENV keeps set as 'development' when I deploy it to firebase functions app.
How can I deploy it as 'development' to firebase?
Those are what I have done to achieve my goal.
Make another firebase project and function for 'production' (Use current firebase project as 'development')
firebase console
Edit .firebaserc file and set aliases for my projects (to use firebase --use command)
.firebaserc
Separate RDS Instance and Slack Monitoring app
Separate .env files with .env.dev and .env.prod and use secrets based on NODE_ENV
set .env files
Add 'dev' script to package.json to deploy as 'NODE_ENV = development'
package.json scripts
This is the code I wrote to find out is which environment my server is running
node_env console.log
And this is from my github actions log and firebase console log
github actions and firebase console log
When I run my app in local with 'serve' command, console.log prints 'development' as I expected.
I guess 'firebase deploy' command automatically changes my NODE_ENV to production when it is deployed.
Or did I make some mistakes to do this?
The recommended way to have a development and production environment is to have two separate Firebase projects, which you are already making use of. For the sake of an example, let's assume you have hyositive-app as your production project and hyositive-dev as your development project.
Defining Deployed Environment Variables
Use of environment variables with Cloud Functions for Firebase are based on .env files compatible with the dotenv package. By default, the following files are supported (ignoring others!):
Name
Purpose
.env
Environment variables common to all environments
.env.<projectID>
Environment variables used when deployed to the named project (e.g. .env.hyositive-app)
.env.<alias>
Environment variables used when deployed to the aliased project (e.g. .env.dev).Note: default is the only alias configured out of the box. dev/prod/etc. are not defined.
.env.local
Environment variables used when using emulating functions on your system using the Cloud Functions emulator.
To use .env.dev and .env.prod, you will need to define them as project aliases in your .firebaserc file (or you can continue using development and production aliases and just update the filenames to match):
{
"projects": {
"default": "hyositive-dev",
"dev": "hyositive-dev",
"prod": "hyositive-app"
}
}
This then allows you to use .env.dev and .env.prod instead of .env.hyositive-dev and .env.hyositive-app respectively.
Using Environment Variables
The Cloud Functions runtime (the process that runs your deployed code) defines a number of built-in environment variables that have various purposes (such as allowing you to use initializeApp() with no arguments).
In addition to these variables, a handful of language-specific variables are also defined by the runtime to aid in painless deployment of code. However, the Cloud Functions documentation states to not rely on their values unless you set the values yourself.
The Node.js Cloud Functions runtime is built using the Cloud Functions Framework (however, it is not guaranteed to perfectly match this open source version). Because this runtime executes using Node.js and makes use of other packages such as express, it sets NODE_ENV to production, to minimise unexpected behaviour that depends on its value. But as mentioned above, this behaviour should not be relied on even though it is unlikely to change.
To override NODE_ENV to development, you would add it into .env.dev, .env.hyositive-dev and/or .env.local (as appropriate). Similarly, you should also define NODE_ENV as production in .env.prod or .env.hyositive-app (as appropriate).
Rather than rely on NODE_ENV, I would recommend defining behaviour around another variable that you have complete control over (such as HYOSITIVE_ENV) or compare against the executing project ID to determine whether it is running in the production project or not.
const PROD_PROJECT_ID = "hyositive-app",
// DEV_PROJECT_ID = "hyositive-dev",
PROJECT_ID = JSON.parse(process.env.FIREBASE_CONFIG).projectId,
isProduction = PROJECT_ID === PROD_PROJECT_ID;
Note: This other thread may have some useful background information.
I develop an application with nodejs and react. I use dotenv for configuration in my different environment.
I use TFS 2017 for build and release my application.
What is the best practise for add my .env file of production environment?
Production configs can be difficult to maintain. You can use any module or even write your own custom module to load environment variable in to your application.
However, maintaining production .env files locally for each product (i.e. committing them or putting them inside your docker image is a bad idea. If you ever happen to change some of those configs, you will have to manually change in the code for each application, build docker image (if required) and redeploy. If there are just a couple of applications, it might be easy. But if the number of related applications grow in size (as usually happens in case of microservice based architecture) - all of them sharing credentials, ips for database connections etc. it becomes a hectic task to manually change code and redeploy all the applications.
Usually, developers tend to keep a central repository of all credentials and environment variables. For examples, AWS offers parameter store and MS Azure offers Azure Key vault. In such a case, all the parameters are fetched during start time, and all we have to do is restart the application.
So usually people set only one global varibale NODE_ENV (as prod or dev), dynamically fetch all environment variables based on NODE_ENV running something like env $(node read-env-variables.js) node app.js.
I was just wondering if there was any standardized convention for .env environment variable files. If I had multiple setups (e.g. development, staging, production), what should they be titled?
I've seen:
.env.development, ...
development.env, ...
settings.development.env, ...
.env, .env.staging, .env.production, ...
If there isn't a standard, are there arguments for which to use (kinda like "" vs '' for strings in JS)? Which do you use and why?
I prefer .env at the end ex: .production.env because last word after . indicates extension. VSCode does not recognize the file as .env file if you do .env.production
VSCode Documentation:
https://code.visualstudio.com/docs/python/environments#_environment-variables
There is only one standard in node ecosystem - use production in NODE_ENV variable for production. It's used by different tools for optimizing.
The rest is on you. But personally, I don't see reasons to make it complex. If you need to differentiate instances further than just production, development, you can use other environment variables.
Also you need to be careful when using different NODE_ENV for staging and production. Because the main purpose of staging is to test everything as close to production as possible. So changing NODE_ENV can be a reason to production fail.
I'm using this convention since I can't find any other suggestions: https://rubyonjets.com/docs/env-files/
.env
.env.development
.env.test
.env.production
I like maintaining the .env at the front and this seems reasonable to me.
This may be a stupid question, but is there a standard/best way to control the environments when deploying through a pipeline (for instance to Heroku).
I have a Node.js app and, for instance, I use 'nodemon' in the "npm start" script I specify in my 'package.json' in dev, but need it to run just 'node' in production when I deploy it.
How do I go about making that change programmatically when I deploy via the pipeline?
I hope that makes sense, thanks in advance!