Support for staging builds

[ehtb]

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.

[gaearon]

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?

[ehtb]

What is your use case for development warnings in staging builds?

Invariant warnings for instance, but also propType checks.

[gaearon]

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.

[ehtb]

Sorry, I meant more descriptive errors in the case of invariants. It serves the same purpose though, by making errors / bugs more transparent.

[ehtb]

I 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.

[msmfsd]

Bump - a staging build script would be good, or possibly the ability to override the NODE_ENV?

[shin-monkey]

YES @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"

[firaskrichi]

What's the alternative right now when deploying? I mean how is it possible to set 'NODE_ENV=staging'

[eshinkawa]

@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".

[firaskrichi]

I meant when deploying. Seems that NODE_ENV is set to production when deploying.

[eshinkawa]

@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.

[firaskrichi]

I just set custom vars on Heroku and it works. Thanks @angusyoung84

[mderazon]

I 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 / .env file.

@gaearon wouldn't it make more sense if NODE_ENV found in shell / .env will have precedence and fallback to 'production' during build time ?

[gaearon]

No, 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.

[gaearon]

Somewhat related: #1070.

But to address your first points:

but with the benefit of non-minimised code including proper sourcemap support

We already include sourcemaps in production builds now.

as well as devtools support.

React DevTools have always been working with production builds.

[mderazon]

I understand your reasoning.

I ended up interpolating index.html on the server, like the docs suggest. I tried to avoid this thing and be 100% client side logic, but it's not that bad.

However, I do think that this hard coded production when building behavior is not "standard" in Node. I expected NODE_ENV to be taken from an env variable and I was a little surprised that it was set to 'production' no matter what I did. Maybe the docs should mention this just to be sure. Maybe here: https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#npm-run-build

By the way, I think the docs are really great! cover every common use case and explains everything really well. Thanks 👍

[gaearon]

Happy to take a PR for docs.

[mbifulco]

Jumping into the fray on this one - @ehtb, have you had any luck putting together a staging PR? It looks like your fork has a fair bit of work done to it. My use case is pretty much the same as yours - I'd like my staging environment to mirror production, but to have traceable code (and use a staging data warehouse, which I'd switch to from the NODE_ENV setting).

[bric3]

I am developing an Application for a desktop app, using Chrome Embedded Frame, and there is a bug with source maps : the devtools cannot load them. Which makes development utterly punishing, exception always at line 3 or 4, forget debug, ...

• https://magpcss.org/ceforum/viewtopic.php?f=6&t=17910
• https://bugs.chromium.org/p/chromium/issues/detail?id=1069378

I really would like a way to alter, overrides the build process without having to eject. At this time the only working solution I've found is https://github.com/timarney/react-app-rewired as it allows to override the webpack configuration.
There is a warning that tool appear lightly maintained, but the version 2.1.8 works with react-scripts 4.0.3

yarn --cwd internal-pwa add react-app-rewired

Here's what my config-overrides.js looks like.

module.exports = function override(config, env) {
    config.mode = "development";
    config.optimization.minimize = false;
    config.optimization.minimizer = [];
    config.devtool = 'inline-source-maps'
    
    return config;
};

This react-app-rewired has been a game changer for me. I hope the react-script tools could provide similar features.

[y-nk]

Sadly adding to the pile of request for this... 5 years after the issue was opened. At some point I'm wondering if someone still really cares about the people using this project. (@gaearon 👀)

Staging builds are a thing, especially in projects/organisations where the established workflow imposes a build to be deployed in a staging environment (through CI) and where you want to keep the flexibility of having an unminified build to allow meaningful bug reporting with the help of the console.

I don't see any valid reason not to have this ; there's no solid case to refute a staging configuration mode as proposed in the original issue ; there's no cost in doing so (the OP was kind enough to give pointers and it seems fairly straightforward), and there's even less reason not to let the consumer pass their own NODE_ENV value (NODE_ENV=development npm run build).

And for sake not letting people do what they wish with their build is nothing but the goal of a convenient developer companion tool.

PS: You're free to delete this comment - i'm probably gonna have to use rewire as i'm certainly not gonna wait 5 more years to see a move.

PS2:

No, this is a dangerous footgun and will result in people unknowingly deploying development builds to production.

The problem isn't the tool in that case, but the people using it. In the same way you can't prevent a person from using a regular screwdriver on a cruciform screw. Add blinking warnings at build time if you wish to prevent and educate them, call the option dangerouslySetNodeEnv= but don't be an ass by blocking them.

[mlynch]

This feature would be very welcome for doing mobile app development with React and projects like Capacitor and Ionic. In those situations you have to deploy a built bundle to a native app container, so having the ability to do a dev build is actually really useful as a development aid. Will look into the workarounds suggested here but hope some day this gets reconsidered!

[jcrben]

My takeaway from this: don't use NODE_ENV in general in my app code, and instead use something I have total control over. Just gonna use something like APP_ENV (or rather REACT_APP_ENV) instead. I don't see how this hurts anything. I'd rather stick to the conventional NODE_ENV tho

[OnkelTem]

The same problem.

React dev builds report about some issues like that popular one with "key", right?
But in production builds they completely disappear leaving bad code untouched.
So what is it in CRA workflow which could prevent this? Nothing. No way to automate this process and catch the warnings.
Only visual console monitoring in the "npm run start" instances....

Don't forget that CRA is more for prototyping, not for real projects folks. Just don't use it for something real.
Unfortunately in our company we made this mistake and now we're stuck to CRA and get ourselves into some trouble like this one.

[biapar]

Really CRA is not for production?

[mungojam]

Really CRA is not for production?

We use it happily in production for many tools

[y-nk]

Don't forget that CRA is more for prototyping, not for real projects folks.

@OnkelTem is there somewhere written something to support that claim?

[joyfuI]

I need the development build feature for dev server!
I hope the discussion on this continues.

[ta32]

Sometimes their are spa's that are more closely coupled to the API or the environment of the backend server. When run from the dev server these bugs are not exercised because all these dependencies are mocked. I basically just ejected the spa.

[cognivore]

I don't want to use rewired just for this. We are trying to test builds inside of a web-component 😢

My plan was to use build for wdio tests under docker-compose, sadly rewired also doesn't allow to trivially re-set the envirnoment.

[chaosmirage]

As a workaround, I have used the https://github.com/ds300/patch-package to build the development version.

I have patched react-scripts/scripts/build.js by commenting the process.env.NODE_ENV = 'production'; line.

[PhilippeFerreiraDeSousa]

Is

NODE_ENV=development react-scripts build

working now?
The internet says to use dotenv, is there magic happening there?

[sytolk]

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');

[el-j]

1. convert your lockfile to version 2

npm shrinkwrap --lockfile-version 2

2. edit node_modules/react-scripts/scripts/build.js
   and change line 12 | 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);

3. use patch-package to create a patch:

npx patch-package react-script

4. package.json change build and add build-dev + postinstall patch

"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

[nezort11]

To fix development builds error:

NODE_ENV=development react-scripts build:

Creating an optimized production build...
Compiled with warnings.

...

ENOENT: no such file or directory, open '/Users/nezort11/dev/d-etf/build/static/js/bundle.js'

You also need to comment printFileSizesAfterBuild code (lines 110-116):

      // printFileSizesAfterBuild(
      //   stats,
      //   previousFileSizes,
      //   paths.appBuild,
      //   WARN_AFTER_BUNDLE_GZIP_SIZE,
      //   WARN_AFTER_CHUNK_GZIP_SIZE
      // );