Regression - cannot define an entry's name

[petemill]

Describe the bug

Before #1619 was released, we could specify an entry point's name via <name>=<path> syntax.
webpack my_file=src/my_file_orig.js my_styles=src/my_styles_orig.scss

What is the current behavior?
Now this is no longer available even in the 4.x branch despite this not being marked as a breaking change and still part of the webpack v4 docs. webpack-cli throws an error

Module not found: Error: Can't resolve 'my_file=src/my_file_orig.js' in ...

To Reproduce

Steps to reproduce the behavior:

echo "console.log('hi')" >> file.js
npx webpack-cli@4.10.0 myname=./file.js other=./file.js

Build fails with the following error:

Module not found: Error: Can't resolve 'myname=./file.js' in

Expected behavior
Build succeeded. And uses entry name ("myname") as output file name.

For example, this works:

npx webpack-cli@3.3.12 myname=./file.js other=./file.js

Screenshots

Please paste the results of npx webpack-cli info here, and mention other relevant information

❯ npx webpack-cli@4.10.0 info

  System:
    OS: macOS 13.0
    CPU: (10) arm64 Apple M1 Max
    Memory: 11.70 GB / 64.00 GB
  Binaries:
    Node: 18.12.1 - ~/.nodenv/versions/18.12.1/bin/node
    npm: 8.19.2 - ~/.nodenv/versions/18.12.1/bin/npm
  Browsers:
    Brave Browser: 108.1.46.133

Additional context

Use-case is to have multiple entry points each with a different output name.
This regressed between 3.3.12 and 4.0.0

[alexander-akait]

Please create reproducible test repo, we have tests on it

[alexander-akait]

And please respect the time of another developers and use the issue template in future, thank you

[petemill]

@alexander-akait I've added the missing template fields and reproducible steps above

[alexander-akait]

I see, sorry, it was a bug in our argument parser, that is why we have this regression, webpack build foo=./test.mjs is misealding syntax and it is not good, because build is a default command (so it can be ommited), i.e. webpack foo=./test.mjs should work the same, but in this case foo=./test.mjs is handled as command for our CLI, yes, we can handle such case and do some workarounds, but it decrease to speed, because we will need to check it is entry and file exists or it is just a command, it is really not good.

So I think we can implement this - webpack serve --entry foo=./bar.js, it will allow to use set a name of an entry and will not overlap with arguments parser logic.

@webpack/cli-team What do you think?

[petemill]

I have updated the description to mention which versions this works and regressed in:

The bug is not present in webpack-cli version 3.3.12 (1.7m downloads in past 7 days on npm)
The bug is present in webpack-cli version 4.0.0.

Regressed between 3.3.12 and 4.0.0.

Also updated the description to show that this worked with multiple entries before the regression was introduced.

[alexander-akait]

I think we will not restore previsoy behaviour, because it will create more bugs due bug in arguments parser, sorry, in your case better to migrate to configurations, for the latest version we will implement --entry-name option, but it will be supported only for webpack v5

[petemill]

My scenario is a dynamic build system, so using configurations isn't a great option for that. But using webpack 5 is if --entry-name can support multiple entries. In the meantime I've had to make custom code to parse entries from custom env arguments.

[petemill]

But based on this decision we should update the release notes to mark this as a breaking change.

[alexander-akait]

Yeah, I agree, but looks like no one faced with it (maybe I am wrong), sometimes it is hard to describe all changes when you change args parser and we were tried to keep compatibility as possible, migration is easy, so let's just close, if someone has questions/issue feel free to open new issue or ping me here

[alexander-akait]

Anyway if sombody wants to describe it or improve - feel free to send a PR too