Preact adding in environmental variables from the system is running on

Preact recognizing system environmental variables so secrets can stay hidden in memory

Hi all,

I’ve combed over Preact documentation, looking at issues and I feel like I’m hitting a wall on trying to get Preact working in a production system. It doesn’t appear that preact can recognize system environmental variables. It can recognize environmental variables if they are set by a .env or by loading them in with the preact.config.js file, but both of these ways are built on it being a file, not a system environmental variable. There doesn’t really seem to be a clear cut way to hide environmental parts except through files which I’m trying to avoid.

Inside the docs on how to use environmental variable: https://github.com/preactjs/preact-cli#using-environment-variables

You can reference and use any environment variable in your application that has been prefixed with PREACT_APP_ automatically:

src/index.js

console.log(process.env.PREACT_APP_MY_VARIABLE);

If your variable is not prefixed, you can still add it manually by using your preact.config.js (see DefinePlugin config in the recipes wiki).

You can set and store variables using a .env file in the root of your project:

.env

PREACT_APP_MY_VARIABLE="my-value"

You can also reference environment variables in your preact.config.js:

 export default (config, env, helpers, options) => {
 	if (process.env.MY_VARIABLE) {
 		/** You can add a config here that will only used when your variable is truthy **/
 	}

};

Additional context

If we are trying to build on a system that defines everything inside a codebase, that means any privy information would have to exist as a form of a file where as if were to load them as a system environmental variable, we could load them in through a scripting process to pull them in from a secrets manager, put them in a tmp fs that only exists in memory and keeping the security of privy information much more secure since the secrets can live outside the codebase and the scripting process can load them in through memory instead of being compromised if an API key lives in a .env file.

I saw this on stackexchange that @rschristian answered and it leads me to believe that preact is not able to recognize system environmental variables.

I also saw more context that DefinePlugin is just acting as a search and replace through this issue

I’m not a preact expert and I haven’t really coded with it, I’m really just trying to get preact working in a productional system that doesn’t use a file to manage environment vars and would like to see this happen. If it does exist, feel free to close this and point me in the right direction.

[scotlyt]

Could also proxy requests? You can have your web app make requests to (say) /api/foo, where your server (be that nginx or whatever) would intercept the /api and direct traffic elsewhere. That’s a pretty common pattern, and avoids having the URL embedded in the app. Depends on your needs.

I was presented a VM with a global nginx with the frontend and the backend is wrapped in docker that has a DB, cache, and other components. The backend also had an nginx piece which I believe now is the global nginx part looking at the config and has location /api/ to itself on a different port &

             location /static/ {
                    root /var/www/html/;
                    autoindex on;
             }

So I’ve been untangling a lot of this, mainly trying to get them into separated areas, fixing the node_modules so they were built within a container (not dependent on the host system) and removing the shared filesystem inside the actual container where the db schema updates were dependent on dev containers.

It sounds to me like a lot of what they did for the frontend interacting with the backend actually looks reasonable except for a part where I saw cleartext for the password field inside the console for preact and I started really digging into more on how the frontend was being built.

[scotlyt]

@rschristian wanted to follow up to all this

there wasn’t any documentation that the assets being built in the one repo were all being copied into folder in another repo that would serve as all the static assets. The issue was that there was already some assets inside there and I was lead to believe that it was two different web apps talking to each other at the start.

Chalk it up to miscommunications and different timezones on working with people more than anything else.

your quote of

This is a pretty esoteric part of modern web dev and varies quite a bit by tool.

pretty much on the nose and assumptions by both sides were made, and no clear lines of communication