It would be great if there was a built-in way to expose build-time environment variables to web/React/Angular projects.
process.env is not exposed, so you have to jump through some hoops and craft a custom solution (e.g. copying files around in a build script, using babel-plugin-preval which comes with babel-loader caching issues, etc.) to read environment variables in web projects (as far as I can tell, anyway).
Prior art for this exists in other popular web frameworks/libraries. create-react-app automatically embeds any environment variable prefixed with REACT_APP_ and Next.js includes an env key in the main config file (evaluated during build) that you can populate as you see fit.
Would either of these approaches be appropriate for Nx, or is there another way that would be even better? Or does an idiomatic way already exist?
Thanks.
Yeah, just encountered this in setting up my first NX project's deployment. Didn't see anything in the docs but I did some across this question. Given you're already referencing a Babel plugin perhaps you've already explored this but it looks like (CI running now) I should be able to move forward with using good 'ole transform-inline-environment-variables.
Here were the changes required on my end:
"webpackConfig": "@nrwl/react/plugins/babel" to my app's build options
.babelrc to my app's root (apps/client-web)json
{
"plugins": ["transform-inline-environment-variables"]
}
Add required dependencies:
yarn add --dev babel-plugin-transform-inline-environment-variables
# I got errors on build for these missing, you may already have them?
yarn add --dev @babel/plugin-proposal-decorators @babel/preset-react @babel/preset-typescript
Hopefully that helps get you on your way!
Yep, that's another way. Thanks for the detailed instructions!
I think one of these approaches should be baked-in, otherwise we'll have various teams doing it different ways in different projects which negates one of the big benefits of something like Nx (IMHO).
Definitely agreed. It feels like something that can be addressed on the
framework level for sure.
That said, I could see an argument for the idea that baked in environment
variable support is overly prescriptive in the face of an alternative like
using a secrets manager or something too.
On Wed, Sep 18, 2019 at 10:34 AM Justin Hall notifications@github.com
wrote:
Yep, that's another way. Thanks for the detailed instructions!
I think one of these approaches should be baked-in, otherwise we'll have
various teams doing it different ways in different projects which negates
one of the big benefits of something like Nx (IMHO).—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nrwl/nx/issues/1848?email_source=notifications&email_token=AALJEJTKKDC6D3A2B37ZJRTQKI36FA5CNFSM4IXGHJGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7AI5IY#issuecomment-532713123,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALJEJXXIQDRKRRABN62RDDQKI36FANCNFSM4IXGHJGA
.
@wKovacs64 @jdpearce @EranSch
We at Blackberry started working on this feature to be part of the framework.
@weblancaster Any luck with the PR?
@footyapps27 made some time and opened https://github.com/nrwl/nx/pull/2502
Most helpful comment
@wKovacs64 @jdpearce @EranSch
We at Blackberry started working on this feature to be part of the framework.