Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Feature/different env config files #1343 #1344
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at email@example.com. Thanks!
If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact firstname.lastname@example.org if you have any questions.
changed the title from
Feature/different config files 1343
Feature/different config files #1343
Jan 3, 2017
I think this is ok for our case at least because that we use
I mean that
So it is not possible to set env variables for build.js. But you can build app bundle according to needed env.
Anyway this depends on developers. Current PR should not answer on this question because CRA started to support
And this is public information so no problems with security.
Passwords, Connection Strings etc. mostly for backend applications. Of course app can be isomorphic but it is architecture depends on its developers and CRA has nothing to do with.
docs also says that having a "main" .env file and an "environment" .env configs like (.env.test / .env.staging) is OK.
Here is additional example from dotenv-rails docs - what .env* configs could be used:
Since there's a precedent, I'm happy to support the exact equivalent of https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use.
Update PR. Seems everything works correctly but I want to check it one more time.
What .env* files are used?
Files priority (file is skipped if does not exist):
Priority from left to right.
@tuchk4 Sorry for the trouble. We merged a long-submitted PR that better modularized the scripts between the files, so that user’s
So ... dotenv FAQ conflicts with this.
Is this PR just moving forward past the dotenv package FAQ advice? I'm just kind of confused. Checking in a
I guess this snippet is how it would work currently without this PR, and this PR does something very similar by convention (file order as described by @tuchk4)? Very cool regardless.
May 12, 2017
This was referenced
May 12, 2017
Because create-react-app does not support a single build that can be configured from the outside via environment variables at runtime, I typically do not recommend it for my clients who follow 12 factor app principles with Docker.
Wouldn't a better approach be to provide a mechanism of runtime injection so if we build a create-react-app inside a Docker container, we can 1) use the same container across environments rather than have to build a separate container per environment and 2) support more dynamic environment-variable based configurations (eg. defer environment variables to the container scheduling phase)?