Proposal: Filter .env variables with WRANGLER_PUBLIC_ check

[ChromeQ]

TL;DR;

With wrangler now supporting .env and .env.development/production files I came across a problem with additional vars being deployed to the workers. My proposal is to allow wrangler to only expose env vars prefixed with WRANGLER_PUBLIC_ are made available to workers env argument.

The problem

I never liked the .dev.vars file, .env has been the convention for years so I was excited to see this support in wrangler, .dev.vars and most .env files have the same problem though, they expose real secrets to developers so I have adopted dotenvx

My situation means I have multiple .env files (.env.development, .env.preview and .env.production), they are encrypted with dotenvx so the values are not plain text. This is a problem in the worker as the value is not "correct" when running on dev and even worse on deployed workers. Let's keep it simple with dev for now:
npx wrangler dev -e development (which reads from .env.development).

The solution is to utilise dotenvx to decrypt them with the private key JIT

npx @dotenvx/dotenvx -f .env.development run -- wrangler dev -e development

This injects the env vars in .env.development to the environment, however wrangler doesn't pick them up so CLOUDFLARE_INCLUDE_PROCESS_ENV=true is required.

npx @dotenvx/dotenvx --env CLOUDFLARE_INCLUDE_PROCESS_ENV=true -f .env.development run -- wrangler dev -e development

But this is not great as it puts about 100 system environment variables into the worker env object, but it does work! My unencrypted values are now available on process.env - the danger of this is exposing too much or relying on a variable which may change depending on system or CI. This is why the CLOUDFLARE_INCLUDE_PROCESS_ENV option is false by default.

The solution

My proposal is to simply filter the variables to only use the ones prefixed with WRANGLER_PUBLIC_ which follows convention which I've previously seen with (now depreacted) Create React App https://create-react-app.dev/docs/adding-custom-environment-variables/ and Expo https://docs.expo.dev/guides/environment-variables/ which re-enforces the idea that some secret vars are "public" and might give a clue to find other solutions, especially when sharing in a team or to customer facing code.

The additional benefit of this filtering is that other env vars are not accidentally deployed to workers, my dotenvx situation adds a DOTENV_PUBLIC_KEY_DEVELOPMENT variable to the .env.development file, although it is public it is probably not desirable to have this deployed as a variable to your workers. The solution allows me to quickly determine and have confidence which variables will be deployed and which are part of my tooling such as CI.

Another additional benefit allows my CI to also simply check if the env var value begins with encrypted: it can deploy them as secrets, and the rest can be added as --var to the deploy command (not all env vars need to be encrypted, non sensitive values can remain plain text such as booleans or feature flags etc). Any keys not prefixed with WRANGLER_PUBLIC_ are ignored by wranger but is still available to my other CI tools.

The code

I have patched the solution myself with patch-package and attached it below (the dist code not src):

diff --git a/node_modules/wrangler/wrangler-dist/cli.js b/node_modules/wrangler/wrangler-dist/cli.js
index fac447e..d2a8889 100644
--- a/node_modules/wrangler/wrangler-dist/cli.js
+++ b/node_modules/wrangler/wrangler-dist/cli.js
@@ -148641,7 +148641,13 @@ function getVarsForDev(configPath, envFiles, vars, env6, silent = false) {
       includeProcessEnv: getCloudflareIncludeProcessEnvFromEnv(),
       silent
     });
-    return { ...vars, ...dotEnvVars };
+    const publicDotEnvVars = Object.entries(dotEnvVars).reduce((acc, [key, val]) => {
+      if (key.startsWith('WRANGLER_PUBLIC_')) {
+        acc[key] = val;
+      }
+      return acc;
+    }, {});
+    return { ...vars, ...publicDotEnvVars };
   } else {
     return vars;
   }

This works perfectly for my use case, although I understand it would be a breaking change so it should be an opt in option perhaps also controlled with another env var! The solution above also works perfectly with wrangler types.

Next steps

I am happy to open a PR to do a full solution including the option and even a customisable prefix but wanted to get feedback before I spend the time on it.