Feature request: support dynamic variable lookup / inject whole process.env

[ghost]

I recently refactored my config logic to use the following code:

/** Get the named environment variable or return the provided default */
const getEnv = (name, backup) => process.env[name] || backup;

/** Ensure the environment variable is defined and return its value, or throw if it is undefined
 *
 * The environment variable is allowed to be empty (or null), as long as it is defined.
 */
const getAndEnsurePresentEnv = (name) => {
  if (process.env[name] === undefined) {
    throw new Error(`Environment variable "${name}" is not defined but is marked as required, aborting.`);
  }
  return process.env[name];
};

Previously, I was doing the same but manually:

// For each variable
export const API_URL = process.env.API_URL || 'http://localhost:8080/';

This refactoring broke the build, since dotenv-webpack only populates explicit variables like process.env.API_URL and not process.env[name] where name = "API_URL".

Would it be possible to add a configuration flag to allow loading all variables defined in the env file, and replacing the whole process.env? Something like

    new DotenvPlugin({
      // load variables from this file
      path: envPath,
      // inject ALL variables, not only the variables explicitly used
      loadAllVariables: true,
    })

[dmca-glasgow]

I was confused by this too when trying this package and using some existing env helper functions, you just need to change your api slightly:

export const env = strVar(process.env.NODE_ENV, 'NODE_ENV'); // pass process.env.NODE_ENV to your helper fn 

function strVar(envVar: string | undefined, key: string, allowEmptyValue = false): string {
  const value = envVar || '';
  if (!allowEmptyValue && value.length === 0) {
    throw new Error(`[env]: ${key} has invalid value: ${envVar}`);
  }
  return value;
}

[mrsteele]

Unfortunately this has been extensively tested. Here you can see my notes as to why this simply isn't possible and the problem is primarily due to webpack: #70 (comment).

@dmca-glasgow sounds like a workaround might be available, but unfortunately this will have to be left alone.

I'm going to close this as its a duplicate of #70 but let me know if you disagree and i'll be happy to open this back up.