webpack-cli@4.0.0-beta.1 still (transitively) depends on webpack@4.x.x

[tlmii]

Describe the bug

Installing webpack-cli@4.0.0-beta.1 still adds the latest webpack @4.x.x to the node_modules folder, even though it directly depends on webpack@^5.0.0-beta.3.

The dependency comes to play via webpack-cli -> @webpack-cli/init -> @webpack-cli/generators webpack@4.x.x

To Reproduce
Steps to reproduce the behavior:

1. Go to a new folder
2. npm init
3. accept defaults
4. npm install webpack@5.0.0-beta.11 --save-dev
5. npm install webpack-cli@4.0.0-beta.1 --save-dev

Expected behavior
I would expect it to only need the already-installed 5.0.0-beta.11.

Additional context
I'm trying to avoid an issue with fsevents@1.2.11, which is an optional transitive dependency of webpack@4 (webpack -> watchpack -> chokidar -> fsevents). I'm willing to move to the beta of webpack 5 for this particular project, but I'm running into this issue with webpack-cli. With that version of fsevents being dropped into node_modules, I can't ever run npm ci, even though we don't actually use anything that would be impacted.

[rishabh3112]

I think #1148 would solve this issue too @ematipico

[ematipico]

I think too

[tlmii]

Thanks folks. Just so I understand - should I just wait for that PR to be merged (it looks like maybe its blocked by the build failures on next at the moment?) or should I try to make another PR that addresses it now?

[rishabh3112]

@tlmii the PR has been merged. This should be available in next release.

[tlmii]

@rishabh3112 Is there a target date for a beta 2? Saw the roadmap but couldn't find a schedule.

[rishabh3112]

/cc @ematipico

[ematipico]

I might be able to ship a new beta this week. Maybe.

[rishabh3112]

@tlmii new version of beta is released, you may check now.

[tlmii]

This looks good. Thanks folks!