As I've read here, React does support environment variables as long as they are prefixed with REACT_APP_. However, I need them in development and production. How can I get this support?
Note: I'm using Next.js
I'm sure this has been answered before, but it says it right on what you linked. Create 2 files, .env.development and .env.production in the root of your project (same level as package.json, .gitignore, etc). Whichever script you run determines which one gets used, in accordance with the hierarchy listed below.
.env: Default.
.env.local: Local overrides. This file is loaded for all environments except test.
.env.development, .env.test, .env.production: Environment-specific settings.
.env.development.local, .env.test.local, .env.production.local: Local overrides of environment-specific settings.
Files on the left have more priority than files on the right:
npm start: .env.development.local, .env.development, .env.local, .env
npm run build: .env.production.local, .env.production, .env.local, .env
npm test: .env.test.local, .env.test, .env (note .env.local is missing)
Related
Is there a way to have a tsconfig sitting in my prod folder to only create sourcemaps if process.env is development? I don't want sourcemaps created during my CI/CD build or pushed to production.
tsconfig was not meant to have stuff like env in the file itself its just a simple json file. To do what you want you should be using your own config for each env aka tsconfig.production.json, tsconfig.development.json
You can then in your build pipeline use the --project/--p command when doing tsc to specify your location. So if you want only prod builds being created in your CI/CD then in your step on executing tsc you can just do tsc -p ./tsconfig.production.json where ./tsconfig.production.json is your path to that file. If you want it to use your env itself most of the CI/CD lets you execute a different script depending on the env so again you just execute this one for prod builds.
Another quick note most people structure their tsconfig files to have a base file which say in this example tsconfig.development.json extends and so does tsconfig.production.json. In the tsconfig.base.json you have all the same main settings so you don't repeat yourself twice, with source maps turned off. Then in the tsconfig.development.json you can extend this file and turn source maps on, to still handle nice debugging when on development.
Anyway i hope this hopes.
I want to do something like this, where, I want to keep all my packages globally just like node package itself. So for example in my package.json I have a package name called "Highcharts" I want to install it globally I don't want to create a local node_modules folder and use it but I want to access it from outside so next time whenever I want to create a copy of my project folder I should be able to use highcharts directly without using npm install. Is it possible?
globally installed node_modules - > Users/user/AppData/Roaming/node_modules/highcharts
app
src
node_modules (I don't want to keep it)
package.json
tsconfig.json
angular.json
How to link these globally installed node_modules with the current app or any app which we want to create?
Any help will be appreciated. Thank you so much :)
local packages are installed in the project directory
global packages are installed in a single place in your system
Usually it is a good idea to have all npm packages required for your project installed locally (project folder). This makes sure, that you can have dozens of applications which are running a different versions of each package if needed.
export NODE_PATH='yourdir'/node_modules
Hello, if am getting right, you want to keep all dependencies global.
You can just run install with -g command. Those libraries will be available in node installation folder.
From the Node docs
If the NODE_PATH environment variable is set to a colon-delimited list of absolute paths, then node will search those paths for modules if they are not found elsewhere. (Note: On Windows, NODE_PATH is delimited by semicolons instead of colons.)
Additionally, node will search in the following locations:
1: $HOME/.node_modules
2: $HOME/.node_libraries
3: $PREFIX/lib/node
Where $HOME is the user's home directory, and $PREFIX is node's configured node_prefix.
These are mostly for historic reasons. You are highly encouraged to place your dependencies locally in node_modules folders. They will be loaded faster, and more reliably.
I hope I answered, you just need to manage the paths to node_modules wherever you have kept it.
My Nuxt project uses system environment variables to set client ids, secrets, urls, etc...
An example is in my nuxt.config.js where I set several properties with the following formula:
{
something: process.env.SOMETHING || 'something_for_dev'
}
Nuxt dev version is working fine because looks after the process.env.SOMETHING and correctly use something_for_dev.
Nuxt on staging has its own configuration on Azure and the SOMETHING env var is correctly set but suddenly it still continue using something_for_dev...
What should I do to let Nuxt use the sys env vars I set on my Server rather than the default used for dev? Thanks
Env variables are set build time, not runtime. So it will be the env variables that set during your build, which seems you do on your dev machine.
So you can either build with proper env variables or use nuxt-env module, which allows runtime variables, but keep in mind that it wont allow webpack to optimize dead code and environment variables used in nuxt-env are exposed client side, so if you store secrets use the secret config option
In addition to Aldarund comment above you could build a proper env variables in nuxt by following:
Use cross-env: npm install cross-env
In your project add a folder named environment
and under the folder you could have different environment (e.g. development, staging, production)
Your environment configs will have your baseUrl and other configs, let's say for development you could have your localhost then for the staging or production you could have your API_URL
defaults.json \\development
defaults.prod.json \\production
In nuxt.config.ts build > extend configure your different environment
This will replace defaults.json depending on which environment we will run our script in package.json.
In package.json configure your script to what environment will be run (e.g npm run start will use NODE_ENV=development which will use the defaults.json with baseUrl: http://localhost:3000 and npm run build will use defaults.prod.json with baseUrl: http://www.API_URL.com and other configs
For more detail you could see cross-env
I often want to bundle a Node package for the browser, but I'm very tired of keeping Webpack configs and all the dependencies in every project directory. It creates enormous bloat, when every project needs a fairly small set of loaders: Mainly Babel, CSS/SASS, *SV and HTML|EJS.
So I tried to write a module called 'bundle-module' that can be globally installed and invoked inside a project to produce a version in a local dist subdirectory, which it creates if necessary. I got the module to successfully generate a config file with absolute paths to the inputs and outputs when you pass the desired filenames, like so:
npm install -g wilson428/bundle-module
# cd /path/to/myproj
# assume myproj has an index.js with it's own
# project-specific dependencies in package.json
bundle-module --name=myproj --entry=index.js
I thought this was working, but it turns out that, when using the Webpack API to call the compilation process, it looks for the loaders in the local node_modules, such that I get this error:
EntryModuleNotFoundError: Entry module not found:
Error: Can't resolve 'babel-loader' in '/path/to/myproj'
This is precisely what I don't want--for every project to need it's own copy of babel-loader and every other loader.
So, if I could speak to Webpack in plain language, I would say, "Please, sir or madam, when looking for a loader, please look in the directory from which you were called, not the directory into which you're compiling`.
The bundle-module package has all the correct loaders and other Webpack modules as dependences (also tried devDependencies). I also tried "pre-requiring" babel-loader, which didn't help.
How can I get a globally installed Webpack instance to use it's local dependencies instead of the project's dependencies?
I think I fixed this, but I suspect there's a better solution:
In the generated config file, I had to use absolute paths to the loaders pointing to the installed modules in the bundle-module directory:
loader: path.join(__dirname, '../node_modules/babel-loader/lib/index.js')
(Curiously, even though the package.json in babel-loader points to lib/index.js, naturally, this only seems to work if the complete path is specified.
I'll leave this unanswered just in case anyone has a more obvious, simpler solution!
I am using react-scripts v2 (beta) and I have read the documentation here.
We need to create many environments.
We want to store env file under folder config/env.
We might use javascript file in config/env/staging.js because .env seems to be only for root directory.
We have real environment :
default
development
staging
preproduction
production
We expect the default environment to be a default config under version control in config/env/default.js, it must be the default configuration used when doing npm start
We expect the user to be able to override with a file with no version control. (something like config/env/default.local.js
Basically that can be reduced to two issues :
Is it possible to relocate env location folder?
How can we create and select a new environment on npm start/build?
without ejecting.
Just copy the environment file to .env before starting / building. You can even put .env in .gitignore that way
"start": "cp $ENV .env && react-scripts start"
Then run it:
ENV=config/staging/.env npm start
There are lots of ways of doing what you want without ejecting, since it's all preprocessing (before your app starts / builds).