Support for staging builds
See original GitHub issueHi, 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
.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:174
- Comments:77 (9 by maintainers)
Top Results From Across the Web
Center stage: Best practices for staging environments
Tips for developing and maintaining staging environments that will help you build more stable software systems.
Read more >The Staging Environment Best Practices These 3 Engineering ...
We need flexible staging environments to support various configurations and ways to simulate vendor behavior. The practices supporting ...
Read more >What is staging environment? | Definition from TechTarget
Staging environments are made to test codes, builds, and updates to ensure quality under a production-like environment before application deployment. The ...
Read more >How to Create a Staging Environment | Cloudways Help Center
Here, a dialog box will appear, prompting some information. 3. Choose the server where you would like to build the staging environment. You...
Read more >What Is a Staging Environment? How to Get It Right - Plutora
Smoke testing, or build verification testing, is a type of analysis that verifies whether a program's critical supporting functions work ...
Read more >
Top Related Medium Post
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
This really should have been as simple as:
$ NODE_ENV=development npm build && s3 sync ./build/ s3://mybucket
You can’t really mistakenly use the dev keys when you’ve explicitly set it on
NODE_ENV
. By forcing the env keys it’s making it worse for everyone, because we can’t easily support multiple environments.You shouldn’t try to save people from mistakes in there deployment process. A framework should provide the tools to support development, and a good one will help avoid pitfalls through documentation but not through pad locks 😃.
Bump - a staging build script would be good, or possibly the ability to override the NODE_ENV?