Repository navigation
Support for staging builds #790
Description
Activity
This is something worth considering for the future although I think we won’t add this near term.
still includes the development warnings
What is your use case for development warnings in staging builds?
What is your use case for development warnings in staging builds?
Invariant warnings for instance, but also propType checks.
Invariant warnings for instance
Which ones are you referring to? “Invariants” are not warnings, those are hard errors and exist both in production and development builds.
Sorry, I meant more descriptive errors in the case of invariants. It serves the same purpose though, by making errors / bugs more transparent.
Reacted by Yazan Alaboudi, shawntherrien, CountZachula and Julien BarbayI just pushed a first idea of how it could work. It uses the production Webpack config as a base and adds the relevant changes on top of it. Other than that it's mostly adding the proper scripts and small modifications. If you consider supporting it, let me know so I can create a pull request.
An alternative option could be to add a minify flag (
react-scripts build --minify=false). We would forego on React's warning etc., which are removed in the production build, but it would make errors more transparent / easier to debug in a staging environment.Reacted by Nathan Moin Vaziri, JoeLangewayClear, lyndon-wu, Scott Anderson and Igor NehoroshevYES @msmfsd ! We need this. Maybe make passible to set NODE_ENV as you like on the build.
Something like:
"NODE_ENV=WHATEVERYOUWANT npm run build"Reacted by Jeff Lomax and Pedro LadariaWhat's the alternative right now when deploying? I mean how is it possible to set 'NODE_ENV=staging'
Reacted by Sagar Jadhav@firaskrichi create a .env file in the root folder of your application, with the variable you want. For eg.: REACT_APP_ENV=whatever
console.log(process.env.REACT_APP_ENV) // will return "whatever".
Reacted by Kevin C, Rene Dohmen, Denis Zhbankov and Ayush NawaniI meant when deploying. Seems that NODE_ENV is set to production when deploying.
Reacted by Jude Wang and Imran Ahmad@firaskrichi indeed.
The only way I could find to control my environments was through custom vars. Since I use Jenkins, I created scripts to build the .env file according to my environment needs.
Right know NODE_ENV is 'development' before building, and 'production' after. You can't edit it.
Reacted by Mike Bifulco, Kevin C, Garys, Jonny Lauriciano, Yuliang Lin, Ayush Nawani, Imran Ahmad and Bryan HoangI just set custom vars on Heroku and it works. Thanks @angusyoung84
Reacted by Eduardo Shinkawa and Ayush NawaniI can confirm that during build time (
yarn run build) NODE_ENV is hard coded to'production'. It doesn't help if you set NODE_ENV to something else via shell /.envfile.@gaearon wouldn't it make more sense if NODE_ENV found in shell /
.envwill have precedence and fallback to'production'during build time ?Reacted by Nick Partridge, Oleksandr Gavenko, Ayush Nawani, Francisco Angelo Cabelo, CountZachula, Crafton Williams and Bryan HoangNo, this is a dangerous footgun and will result in people unknowingly deploying development builds to production. Unfortunately I've seen this enough times to know it has to be hardcoded, and if we want to expose a separate build mode, it needs a separate command that you wouldn't confuse with a regular build.
Reacted by karlismelderis, aaristotle75, clapas, CountZachula, Joachim, folfix, Michał Matyas, Keith Valin, Philip Nilsson, Scott Anderson and 31 moreReacted by karlismelderisReacted by CountZachula and Joachim75 remaining items
With resct-scripts v5 work this in
react-scripts/scripts/build.js. It will force webpack development build// Generate configuration const config = configFactory('development'); // configFactory('production');
Reacted by Fabian Althaus [el-j]- convert your lockfile to version 2
npm shrinkwrap --lockfile-version 2- edit
node_modules/react-scripts/scripts/build.js
and change line12 | 13+58:
// process.env.BABEL_ENV = "production" // process.env.NODE_ENV = "production" process.env.BABEL_ENV = process.env.NODE_ENV process.env.NODE_ENV = process.env.NODE_ENV // const config = configFactory("production"); const config = configFactory(process.env.NODE_ENV);
- use patch-package to create a patch:
npx patch-package react-script- package.json change
buildand addbuild-dev+postinstallpatch
"scripts": { ... "build": "NODE_ENV=production react-scripts build", "build-dev": "NODE_ENV=development react-scripts build", "postinstall": "npx patch-package" ... },
thanks for the idea @sytolk @chaosmirage
Reacted by xiaohundun, Sendu Bala, Alex Counsell, Bez and MattReacted by Rade Martinović and Vadim Birkos- added a commit that references this issue
on May 2, 2025 - added a commit that references this issue
on Sep 24, 2025
Hi, I thought about adding support for staging builds. I am not sure if this requires ejecting though, or could be a feature of CRA.
Our use case is that we create staging builds to deploy to our staging servers. This allows us to debug the app in a production like environment, but with the benefit of non-minimised code including proper sourcemap support and still includes the development warnings and notifications, as well as devtools support.
It can look very similar to webpack.config.prod.js, but with changes to L52-L54 and removal of
webpack.optimize.UglifyJsPlugin.