Webpack-cli: Unknown argument: --env

[Namchee]

Describe the bug

I'm trying to set my webpack env for configuration purposes with

webpack --env.platform=node

But, webpack-cli keeps throwing ⬢ webpack: Unknown argument: --env error to me

What is the current behavior?

webpack-cli refuses to read the flag and throw an error instead

To Reproduce
Steps to reproduce the behavior:

Just try to add --env flag to any webpack command.

Expected behavior

webpack-cli should accept and set this variable correctly

Screenshots

Additional context

This works on 3.3.10. I'm currently using 4.0.0-beta.2

[lobsterkatie]

I am having the exact same problem with the mode flag. And yet the docs still include it, and the migration guide for webpack 4 -> 5 mentions it, so it's pretty clear it hasn't been removed... Very confused with this one.

[ematipico]

Please don't install 4.0.0-beta.2 just yet. Unfortunately I published an incorrect version on npm, so sorry about that. Please keep using 3.3.10 or 3.3.11.

In 4.0.0-beta.2 we removed --mode and --env. If you feel you'd need that argument back, feel free to leave a feedback here

[robertlevy]

I'm seeing this issue in the 4.0.0 release

[anshumanv]

Hi, @robertlevy we've changed the env flag format in v4 because we changed the arg parser, new docs will be released on official site soon. Meanwhile, you can use CLI docs from this deployment - https://vercel.com/webpack-docs/webpack-js-org/e6mjiydwu

[robertlevy]

@anshumanv thanks but that link is not working for me. could you paste a summary or working example?

[anshumanv]

@robertlevy ofcourse! You should get a good idea from this test - https://github.com/webpack/webpack-cli/blob/master/test/config/type/function-with-env/function-with-env.test.js

Let us know if you run into any problems 😄

[thealjey-eib]

@anshumanv
so, env now only supports boolean values?
I need to be able to pass arbitrary strings from the command line.

[snitin315]

but we cannot pass an arbitrary string from the command line?

@thealjey-eib You can pass any arbitrary string from the command line.

[thealjey-eib]

@snitin315 how?

it used to be as simple as
webpack --env.app=foobar --env.title=qwerty
but, now this throws "Unknown argument" errors

this creates variables with names app=foobar and title=qwerty, and values true
webpack --env app=foobar --env title=qwerty

[anshumanv]

@thealjey-eib for now yes, this is how the behaviour was restored when it was removed.

You can use

webpack --env appFoobar --env titleQwerty

And use these variables to write conditional logic in your config, does it not cover your use case? If not, please give an example.

[fabianmarcus]

@thealjey-eib for now yes, this is how the behaviour was restored when it was removed.

You can use

webpack --env appFoobar --env titleQwerty

And use these variables to write conditional logic in your config, does it not cover your use case? If not, please give an example.

I am used to do it this way:

npx webpack --mode production --config webpack.config.build.js --env.name="[staging|production]" --env.service="[login|flight|reservation|...]"

Now I get
[webpack-cli] Unknown argument: --env.service=staging
[webpack-cli] Unknown argument: --env.name=login.

What's the working equivalent in Webpack CLI 4.x and Webpack 5.x?

When I change the syntax to your example, the properties in env are just booleans:

npx webpack --mode production --config webpack.config.build.js --env name="[staging|production]" --env service="[login|flight|reservation|...]"

# Result in env
{ 'service=staging': true, 'name=login': true }

But that's not what I need.

[anshumanv]

Thanks for the examples, migration of both config and scripts to use booleans will add a considerable overhead and current format seems not the most verbose thing to work with. I've opened https://github.com/webpack/webpack-cli/issues/1932 to track it, will PR soon

Since we've migrated our arg parser to commander so --env.name="staging" --env.service="login" won't be possible but we can do --env name=staging --env service=login Is that something you can work with?

[fabianmarcus]

Is that something you can work with?

Yeah, of course. Thanks!

[thealjey-eib]

@anshumanv my example is a multi-application project
I have an "applications" folder and I want to build any one of them by name.
Maybe env is not ideal, I do not know, but I have not been able to find a better way to pass custom variables into webpack.config.js
I cannot hardcode the names of every app in webpack.config.js, and even if I did a boolean value is just not suitable for getting a single value from a list.

[anshumanv]

@thealjey-eib

If you have a config per application, you can use flag --config-name to run webpack for just that config with that name, maybe it suits your use case better, can you try using that?

[thealjey-eib]

I don't want a config per application either, because they would all be the same.
It would only complicate things.

[anshumanv]

Ah okay so you have a single config for all applications, then env is the way to go 👍

[evolopment]

The documentation still has the old format, I've just had the same problem for following the docs:
https://webpack.js.org/guides/environment-variables/

[chenxsan]

@evolopment Maybe you can help fixing it :) Here's the source page https://github.com/webpack/webpack.js.org/blob/master/src/content/guides/environment-variables.md to edit.

[evolopment]

PR sent. Thanks.

[ghost]

Can there be some easy to find simple fix for this? A lot of people are going to be running into this now, I read the comments and I'm still not sure what the exact fix is

[snitin315]

@cranphin see https://github.com/webpack/webpack-cli/pull/1939 for new --env format.

[ZebraFlesh]

This is a breaking change that really needs to be called out as such. In addition, I don't think webpack-cli 4.x can claim compatibility with webpack v4 with this change -- the --env.prod=foo form is explicitly called out in the webpack v4 docs. If there is no desire to undo this change, then the peerDependencies should change.

[AsebWebDev]

So, setting up the enviroment variables like this is the way to go: --env prod=foo - no dot notation.

[snitin315]

@AsebWebDev yep exactly!