A way to define custom environment variables

[meghprkh]

This may be a tiny yet non-obtrusive solution. Allow a custom .env.js file that exports a key value pair used for custom webpack defines. I guess this wont be useful for many, since you any way get to refer to NODE_ENV but I also used this for defining a publicPath from an environment variable or defaulting to root. (useful for me as i had to run the same app for multiple quizzes, so I could build the frontend without configuring anything and having sane default not-get-in-the-way configs while development and testing)

[gaearon]

Can you please clarify your use case in a little more detail? I'm specifically interested in the problem you were solving (configuring for multiple quizzes?) than the exact proposed solution.

[dmi3y]

I might have one. Let's say there is api server running at different enviroments like so:

• dev.api.foobar.com
• prod.api.foobar.com

And I'm building SPA which supposed to use CORS and being hosted anywhere, just like static site.

And such I want to supply dev/prod absolute paths for different versions of SPA.

Hope this makes sense.

[mxstbr]

I think at that point you have a very advanced use case and ejecting is the way to go. I don't think adding .env support by default is really necessary, since most users will never need it?

[meghprkh]

@mxstbr Yes may be true, but I just wanted to open this for some discussion, please feel free to close it.

I try to explain my use which is somewhat similar to @dmi3y's usage:

• I have a quiz app
• I deploy it to multiple subpaths inside one domain, as in one on /quiz1 and other on /quiz2
• This is easy using an environment variable based config of publicPath and I use that also in the .env.js file so that it is accessible to the main app.

Basically the .env.js file can act as a way to preprocess any constants without having to include any file in the main app. So for example if we are going to use homepage of package.json, we can include package.json in the .env file and export the constants after a little modification also. However if we do this in the main app, it is not preprocessed and package.json will be included in the app bundle also. While not an issue here because it would be anyways minifed, it will be an issue when we have to use a node module for generating a constant and thus bundle size may increase or it may not work

This is an advanced use case but not a obtrusive solution (not needed but can be provided kind of thing).

I hope this explains clearly the purpose.

[mxstbr]

Yes may be true, but I just wanted to open this for some discussion, please feel free to close it.

Absolutely no fault in that, we're definitely not saying create-react-app is perfect by far! Discussions like these could open our eyes to use cases we haven't though of, they're incredibly important.

I'm not sure I fully understand your use case, wouldn't you need access to the webpack config anyway if you're changing the publicPath?

[meghprkh]

@mxstbr not as per #21 where it would be automatically understood from package.json's homepage

[d-gubert]

Something I missed when trying create-react-app in a cloud9 free workspace was the ability to set a custom IP and PORT for the server to listen to.

I was able to achieve that by manually changing thestart script in react-scripts, but I think using environment variables for that would be much simpler, even more for begginers.

[tyrbo]

^ That's also my use case.
I need to adjust the ip/port for usage on Cloud9.

[vjeux]

I'm curious, can you explain how the workflow works with cloud9? Do you have the developer server running in the cloud and use their browser text editor to edit the code? Where do you see the terminal output? Why not develop locally?

[d-gubert]

I mainly use this kind of service (Cloud9, Nitrous.io, etc...) when I'm at work and don't have access to my PC.

They're also a good place to study with friends, since they allow collaborative coding. Plus, somewhere free to showcase a small app?

And yes, you use their browser text editor to edit the code and there's also a terminal emulator in the text editor.

[lacker]

One use case I often have for environment variables is when I want to run some code in production but not in development. For example, if you're using an analytics service, you might not want to log any analytics from development versions of the app. Or if you use an external service to sign people up for a mailing list, you don't want your test accounts getting in there.

About Cloud9, one situation I see it adopted more and more is for education. If you're teaching a class of people how to use some technology, you don't want to spend a ton of time making sure everyone has their development environment set up. If you can just give them one Cloud9 config they can get going quickly. So it would be pretty nice to support Cloud9. They also just got acquired by Amazon to be integrated into AWS, which is another sign this sort of thing is going to grow in popularity.

[gaearon]

One use case I often have for environment variables is when I want to run some code in production but not in development.

We currently already allow this with process.env.NODE_ENV checks. This is how React determines which code path to use.

So it would be pretty nice to support Cloud9

Absolutely agree. I just want us to learn more about different use cases first, and approach the problem holistically, rather than add flags one by one over time. A holistic solution might turn out to be simpler.

[lacker]

One use case I often have for environment variables is when I want to run some code in production but not in development.

We currently already allow this with process.env.NODE_ENV checks. This is how React determines which code path to use.

Hmm good point. Here's a slightly different example - let's say your app accesses a Firebase backend. There is one that's only used for production, but each developer has their own for local development, so you can stick random experimental stuff in your database without it borking other peoples' environments. One pattern I would use for this is to check an environment variable to get access info for the backend, and have a startup script for development mode that grabbed this from a config file that isn't checked into source control. Is there currently a straightforward way to do this within a create-react-app-created app?