webpack-stream 7.0.0 throws an error: Cannot find module webpack/lib/ProgressPlugin about webpack-stream HOT 6 CLOSED

Faced similar error and running npm install --save-dev webpack did solve the problem. Thanks!

from webpack-stream.

You are correct. Peer dependencies are an awful user experience. See #241 (comment)

from webpack-stream.

Peer dependencies may be a bit complexer, but also provide a lot of improvements when done correctly.

from webpack-stream.

My negative opinion on peer dependencies comes from being on the Grunt and webpack teams as well as maintaining and interacting with many frameworks and plugins but that was awhile ago, so maybe things have changed. If you got some examples of them being done correctly, I would love to see them and copy their work because I have no idea how to do them correctly.

I much prefer just declaring dependencies that for sure will work with the library and then provide a dependency injection mechanism to override a peer dependency. Maybe the injected version doesn't work but it is explicit to the end developer as they are injecting it. The problem is exacerbated as you add more plugins with overlapping compatible framework versions hence the added resolutions feature of package installers... but even that fails if not all the plugins are compatible with the resolved framework version. You're stuck waiting on all the maintainers of each plugin to update to progress up in versions.

from webpack-stream.

Hey shama,

with correct I meant more "at the right position, not for everything, just like needed", but that also changed a few times for me :D And while writing the rest of this comment, realized for me it is more a "is it a plugin for something or is it using that something standalone" question.

For "NodeJS/backend"

peer-deps aren't so important imho

• mostly no problem with installing the same stuff multiple times
  • with especially the pros you already listed :)
• problems occur when: an installed package is using a package and that package is using some global configuration
  • like webpack
  • if installed two times, the configuration/internal state may not be in sync anymore
  • when not installed by user, sometimes this leads to very strange issues when the user wants to intercept e.g. webpack in his own code again

For frontend stuff

• installing a dependency multiple times, in different versions, will increase the bundle size
• enforcing to have "bigger" dependencies as peer-dependencies makes a lot of sense to not have them duplicated, ever
• people think more (hopefully) if they see that they need to install 10 more packages
• e.g. my eslint will warn if importing packages that are not installed through my projects package.json
  • or the library, that is using those dependencies, need to reexport it

To be honest, don't have that much examples in my mind atm., maybe remembering some in the next days.

• @material-ui/core is a general peer-dependency of my @ui-schema/ds-material, thus allowing the user to install like neccessary, as imho people will more likely install @ui-schema to an existing @material-ui codebase and not otherway arround - but i'll include immutable in the future, so this won't be a peer-dependency anymore
• @babel plugins in general, you install babel, then the plugins, not expecting that the plugins include babel

When using webpack-stream, then webpack should be provided by the user imho, as it may integrate into an existing codebase where webpack already exists or should be used even without webpack-stream. Like with babel, as webpack-stream is more a plugin for webpack, you don't expect a plugin to include the programm it integrates into.

Side note: the newer npm versions (since v7) warn/fail when installing the wrong peer-dependency, thus some of the DX has been optimized, but that means the published packages need to correctly tell their valid peer-dep versions.

from webpack-stream.

Thank you a lot! Your solution helped me. The solution is: npm install --save-dev webpack

from webpack-stream.