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

In starting we dropped the support of --env but as per feedback of users, We have added back the support of --env in 72491539bb06986d28bd55a1b112760435cade9d .
Maybe you should try it once again with webpack-cli next branch
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 ?
I think we support it like --env <development | production | none>, and not like the old cli.
/cc @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?
--env params is also unknown

And yes, i need multiple env vars management to customize entry points from my dockerfile.
Unusual, seems to be working for me

Maybe the problem is that I retrieve webpack-cli-monorepo from github ?
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"
@xylolink added support for multiple env in https://github.com/webpack/webpack-cli/pull/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
@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
we can support
--env test-version test-cli => { test-version: true, test-cli: true}.
+1 from my side on this.
@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 馃憤
@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
@anshumanv
webpack-cli --env test-version --env test-cliis right syntax, using--env test-version test-cliis 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
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
Agreed.
Should we close this?
I think yes, we fix it
Closing, feel free to open a new issue for any feedback/problems. 馃槃