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.

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 ?