Document how to works with environment variables

[Kocal]

Just a reminder to write a documentation for Encore.configureDefinePlugin(), and the integration with Symfony .env files and process.env.*.

• https://github.com/motdotla/dotenv

Encore.configureDefinePlugin(options => {
  options['process.env'].MY_OPTION = JSON.stringify('foo');
});

For example for configuring sentry DNS from .env file:

Encore.configureDefinePlugin(options => {
  const env = dotenv.config();
    
  if (env.error) {
    throw env.error;
  }

  options['process.env'].SENTRY_DSN = JSON.stringify(env.parsed.SENTRY_DSN);
});

[Lyrkan]

We'll have to be careful about that one: there could be confusion related to the fact that it will be interpretated at build time and not on the server it'll be deployed to (like Symfony).

[Kocal]

Yup, we should note that

[Kocal]

In fact, what about adding a new method like .injectEnvironmentVariables(['NODE_ENV', '...']) that will:

• resolve environment variables like Symfony do
• automatically inject them with DefinePlugin + JSON.stringify

?

It can be a bit hard to implement it properly, but it will be 100 times more user friendly

[anaelChardan]

What about this issue ? Would be very helpful ;)

[Kocal]

A proposal has been opened on #568, but it's totally not an easy feature in fact :p

[yaotzin1]

I start using https://www.npmjs.com/package/dotenv-webpack in my project.

After installation:

In webpack.config.js import it:

const Dotenv = require('dotenv-webpack');

Add it as plugin:

.addPlugin(new Dotenv( { path: './.env.local', systemvars: true } ))

start using it in code:

{process.env.npm_package_version}

@anaelChardan

[veewee]

When used wrong, dotenv-webpack can leak e.g. the database connection string into public JS code.
I made a little plugin based on dotenv and define that only includes PUBLIC_ prefixed env vars from both .env and .env.local

.addPlugin((() => {
        const parse = (envs) => envs.reduce((env, current) => {
            if (current.errors) {
                console.error(current.errors);
            }

            return {
                ...env,
                ...Object.fromEntries(
                    Object.entries(current.parsed ?? {})
                        .filter(([key]) => key.startsWith('PUBLIC_'))
                        .map(([key, value]) => [`process.env.${key}`, `"${value}"`])
                )
            };
        }, {})
        const log = (result) => {
            console.log('Loaded public .env vars', result);
            return result;
        }

        return new DefinePlugin(
            log(
                parse([
                    Dotenv.config({path: '.env', override: true}),
                    Dotenv.config({path: '.env.local', override: true})
                ])
            )
        );
    })())

[DmitryLanda]

If you want to follow the way Symfony works with .env files you can use the dotenv-webpack and the config below

Encore.addPlugin(
  new Dotenv({
    path: ".env.local",
    defaults: ".env",
    systemvars: true,
    allowEmptyValues: true,
  })
)

Unfortunately it will not let you follow all the .env.* files Symfony use, but it will follow this order of fallbacks:

1. Check var in system (process)
2. Check var in .env.local
3. Check var in .env

[carsonbot]

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

[pudovmaxim]

I would like to warn against using environment variables when building a project with Webpack. Unfortunately, the documentation does not clearly address this issue.

According to the "twelve-factor app" principles:

Config varies substantially across deploys, code does not.
A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials.

Therefore, you should not use any data from the environment when building assets.

I believe params should be passed as constant on page render. This approach allows you to dynamically change the environment without modifying the build process.

Additionally, many tips that recommend using the dotenv package for working with environment files fail to mention that its behavior differs from the standard environment file loading process in Symfony applications.

In my opinion, the best approach would be something like this:

  .configureDefinePlugin(options => {
    if (process.env.APP_ENV) {
      dotenv.config({path:'./.env.' + process.env.APP_ENV + '.local'})
      dotenv.config({path:'./.env.' + process.env.APP_ENV})
    }

    dotenv.config({path: './.env.local'})
    dotenv.config({path: './.env'})

    options['process.env'].APP_TOKEN = JSON.stringify(process.env.APP_TOKEN)
  })

To build with a production "Symfony-like" environment and Encore development build, you can run:
APP_ENV=prod yarn encore dev.

[pudovmaxim]

And be careful, npm dotenv read this .env without error:

 ) ( *T& ^ R% ^%E ^%F &some wrong string i-0eemf 0af09
APP_TOKEN=abc

But php Symfony\Component\Dotenv fail as expected.

[jomakori]

how about situations when using cli tools like doppler - which uses the cli to pass in the secrets as env vars (on-demand) or when using Kubernetes external secrets operator to pass in the secrets to your running app container? @pudovmaxim

[Kocal]

I believe those environment variables should be available from process.env