implement built-in .env support

[alexander-akait]

I think we need to implement built-in .env support, there is a good plugin https://github.com/mrsteele/dotenv-webpack

Describe the solution you'd like

Allow to red env variables from .env file and control it using CLI option

Describe alternatives you've considered

No need

Additional context

No need

[silverwind]

How about supporting vite's files? I think multiple files are almost required if you have default vars checked in git and then have another file to override those vars at build time. If the same files as vite could be supported, it'd be some nice compatibilty.

[alexander-akait]

Yeah 👍

[mertcanaltin]

@alexander-akait I want to do this 🚀
Would it be weird to add webpack config to the home directory? 🤔

[webpack-bot]

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[silverwind]

@webpack-bot keep open.

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

[Sakib25800]

@alexander-akait, it looks like this feature was close to completion in #3759 but was closed due to inactivity. Could I perhaps submit a new PR picking up from where it was left off previously?

[alexander-akait]

@Sakib25800 Yes, you can

[alexander-akait]

To be honestly not sure we really need this right now, because we have https://nodejs.org/en/learn/command-line/how-to-read-environment-variables-from-nodejs, I think we need update our docs and that's enough, we provice an example how to use them in webpack.config.js and as a build time variables using DefinePlugin({})

And both things already work good, but only for Node.js 20

So let's update documentation and that's all

[alexander-akait]

@snitin315 Do we have example to how to using .env files here or on our website?

[silverwind]

To be honestly not sure we really need this right now, because we have https://nodejs.org/en/learn/command-line/how-to-read-environment-variables-from-nodejs

Node's dotenv support is limited to a single file though. Often it's desirable to support two files, one checked into git, and one not. Vite does support .env and .env.local for this, see https://vite.dev/guide/env-and-mode#env-files.

Also https://github.com/motdotla/dotenv-expand is a very useful addon that is not supported by node's loader.

[alexander-akait]

@silverwind

Node's dotenv support is limited to a single file though.

From docs:

You can pass multiple --env-file arguments. Subsequent files override pre-existing variables defined in previous files.

So you can use node --env-file=.env --env-file=.env.local webpack.config.js, so multiple files are supported

Yes, it's a bit wordy. But it works.

Also https://github.com/motdotla/dotenv-expand is a very useful addon that is not supported by node's loader.

Node.js team is working on it, so I think it will be implemented in the near future.

Also we have https://nodejs.org/dist/latest-v22.x/docs/api/process.html#processloadenvfilepath

[silverwind]

Yes, it's a bit wordy. But it works.

Ah great. I wasn't following the feature recently, this must've been a new addition I've missed. In that case. I think it should be fine to rely on that feature and not re-implement it. dotenv-expand is certainly a more rarely needed thing, but I do make use of it in some of my vite projects.

[alexander-akait]

Yeah I think so, anyway providing them in DefaultPlugin by default will be great too, so maybe we still need a small code for such feature

[silverwind]

For me both ways work, but I guess the general userbase would appreciate not having to touch NODE_OPTIONS and have it work out of the box, e.g. webpack calling loadEnvFile on the same patterns that vite supports.

[alexander-akait]

@silverwind Yeah, it sounds good for me too, should be not hard to implement, we need to implement --env-file or --env-file [string] for our CLI:

If true:

webpack calling loadEnvFile on the same patterns that vite supports.

If it is string/multiple string we try to load them in order.

Also make sense to have --env-file-if-exists too

dotenv-expand can be implement like a feature

So yes, PR welcome

And also there are more options - https://github.com/mrsteele/dotenv-webpack?tab=readme-ov-file#properties, but I don't think we really need them all (they maybe implement like a features too)

[silverwind]

we need to implement --env-file or --env-file [string] for our CLI

Not necessarily, NODE_OPTIONS="--env-file=.env --env-file=.env.local" npx webpack should already work.

I think i'd even be against the user being able to specify filenames, as this part is unconfigurable in vite too, it always loads the same 4 files.

[alexander-akait]

@silverwind

Not necessarily, NODE_OPTIONS="--env-file=.env --env-file=.env.local" npx webpack should already work.

Yeah, but it loads env variables only for configuration file, if we need to pass them to runtime code we need to use DefinePlugin(), but how we can understand which env variables were loaded from env files (Node.js doesn't have API for this).

Using NODE_OPTIONS="--env-file=.env --env-file=.env.local" npx webpack will work, yes, but in such case you need directly using DefinePlugin() and pass them into the plugin that they became runtime-time values.

My idea is implement the same logic (using loadEnvFile) but make it more smarter

[Sakib25800]

@alexander-akait / @silverwind

To clarify, my understanding is:

1. Automatic loading of env files following Vite's conventions and priority
2. Bridging env variables to the bundled code: using Node.js's loadEnv file API to read env files
   • Automatically configuring DefinePlugin() with loaded variables

Let me know if I've understood correctly so I can work on it

[alexander-akait]

@Sakib25800 Yes, that is a minimum logic we need right now