v4-beta : use env variable with config as a function

[xylolink]

Describe the bug

We need to manipulate env vars in the config file to adjust the compilation entries points

What is the current behavior?
Cli does not recognize --env.MYVAR parameter
Config returning this kind of result is not considered by CLI without any error message :
module.exports = (env) => { return { // my conf }

To Reproduce

encapsulate your config object in a function and try to compile it.

Expected behavior

CLI should receive config functions and --env parameters

Screenshots

Compilation results without function

Compilation result with function

Unknown --env params

[snitin315]

In starting we dropped the support of --env but as per feedback of users, We have added back the support of --env in 7249153 .
Maybe you should try it once again with webpack-cli next branch

[xylolink]

Ok thanks !

I tried to update my npm. with npm install --save-dev git://github.com/webpack/webpack-cli.git#next webpack@next

Here's my package.json update :
{ "webpack-cli": "^4.0.0-beta.8", "webpack-cli-monorepo": "git://github.com/webpack/webpack-cli.git#next", }

But cli still does not recognize --env.VAR

Any idea why npm is not taking the last version ?

[snitin315]

I think we support it like --env <development | production | none>, and not like the old cli.
/cc @anshumanv

[anshumanv]

I tried to update my npm. with npm install --save-dev git://github.com/webpack/webpack-cli.git#next webpack@next

Hey @xylolink 👋

The env flag presently only supports string in the format --env TEST, are there use cases when you need a object?

[xylolink]

--env params is also unknown

And yes, i need multiple env vars management to customize entry points from my dockerfile.

[anshumanv]

Unusual, seems to be working for me

[xylolink]

Maybe the problem is that I retrieve webpack-cli-monorepo from github ?

[anshumanv]

Yes, seems so. Can you try to update your package.json like this and try reinstalling?

"webpack-cli": "git://github.com/webpack/webpack-cli.git#next"

[anshumanv]

@xylolink added support for multiple env in #1715

But the syntax is slightly different because we're using a different parser now,

webpack-cli --env test-version --env test-cli which will make the env param as

{ test-version: true, test-cli: true} so you can destructure these things from your env param and use to structure your config, is that something you can work with?

/cc @evilebottnawi

[snitin315]

@anshumanv with commander 6 now we can support --env test-version test-cli => { test-version: true, test-cli: true}.

Should I create a PR for the same?
Reference https://github.com/tj/commander.js/#variadic-option

[rishabh3112]

we can support --env test-version test-cli => { test-version: true, test-cli: true}.

+1 from my side on this.

[anshumanv]

@anshumanv with commander 6 now we can support --env test-version test-cli => { test-version: true, test-cli: true}.

yep that will be good, go ahead 👍

[alexander-akait]

@anshumanv webpack-cli --env test-version --env test-cli is right syntax, using --env test-version test-cli is misleading can be create potential problems like --env test-version ./src/index.js

[snitin315]

@anshumanv webpack-cli --env test-version --env test-cli is right syntax, using --env test-version test-cli is misleading can be create potential problems like --env test-version ./src/index.js

It can cause trouble in this case but might be handy for cases when we have long flag name like, weback-cli --resolve-alias-alias alias1 alias2 --resolve-alias-name name1 name2

[alexander-akait]

For complex cases you should use webpack.config.js, no need to support misleading behavior weback-cli --resolve-alias-alias alias1 alias2 can be weback-cli --resolve-alias-alias index.js main.js and you can never understand what the developer meant

[snitin315]

Agreed.

[anshumanv]

Should we close this?

[alexander-akait]

I think yes, we fix it

[anshumanv]

Closing, feel free to open a new issue for any feedback/problems. 😄