Webpack-encore: Not possible to use encore without warnings

[mmarton]

It's not a serious problem, just an annoying thing. :)

If I add encore to my package.json as a devdependency i get the warning:

Webpack is already provided by Webpack Encore, also adding it to your package.json file may cause issues.

If I don't add it and use anything that depends on webpack I get a warning at yarn install/upgrade:

[email protected]" has unmet peer dependency "webpack@^3.0.0 || ^4.0.0".

and same warning with @babel/core

I've found this https://github.com/yarnpkg/yarn/issues/5347 and the link on the closing comment https://yarnpkg.com/blog/2018/04/18/dependencies-done-right/#a-simple-rule

I'm not sure what could be the solution, maybe encore should only peerdepend on the mentioned libs?

[weaverryan]

I've thought a lot about this, and I also dislike these errors. But, it's tricky. We're not a true peer dependency - we really are calling webpack directly from our CLI tool and requiring it directly. On the link you listed, we sorta satisfy both sides of the simple rule.

For that reason, I originally decided to make webpack a true dependency. This also simplifies what the user needs to have in their package.json file. I don't feel a lot of motivation to change it, until/unless it starts causing concrete problem.

Cheers!

[ghost]

if you read the message closely it meantions peer dependency. So all yarn really wants is for you to do this, basically:

‘yarn add -P webpack’

Yarn is then satisfied and it won’t overwrite the existing webpack configuration

That’s a short term fix. I think Encore should make these optional dependencies

From my limited (and admittedly not deep) testing it worked for me.

https://yarnpkg.com/lang/en/docs/dependency-types/

If you’re not publishing a Frontend library it should have no adverse effects

[Lyrkan]

@ProtonScott I don't think that's right either since it would mean that the app/lib you are working on depends on Webpack being installed (which is probably not the case).

As @mmarton said, if we wanted to be semantically correct the peer-dependency should be declared in Encore's package.json, but I kinda agree with @weaverryan... it would make Encore a bit harder to use, only to remove those warning messages.

[mmarton]

I see your points. It's just having warnings as the expected behavior is just makes an unprofessional impression. Not something I would expect from an official symfony tool.
But I think its okay before release v1.0.

[bobvandevijver]

This is currently still a thing. Maybe the warning should mention that you can solve this by adding Webpack as peer dependency to your project?

[AktasC]

This is currently still a thing. Maybe the warning should mention that you can solve this by adding Webpack as peer dependency to your project?

Yeah but when you do that Encore tells you to avoid adding webpack to your package list...
Replacing a warning with another is not a "solution" per se...

[gerryvdm]

I was able to suppress this warning by adding the following to my project's package.json file:

    "resolutions": {
        "webpack": "4.41.5"
    }

This does seem to fix the installed version of webpack to the version specified though.

[codepushr]

I also managed to solve it temporarily by checking the used webpack version inside encore (for me ^4.20.0) and manually setting the peerDependencies and resolutions fields like so:

"peerDependencies": {
  "webpack": "^4.20.0"
},
"resolutions": {
  "webpack": "^4.20.0"
}

[GPHemsley-RELX]

OK, so, webpack is both a dependency and a peer dependency.

The warning says:

Webpack is already provided by Webpack Encore, also adding it to your package.json file may cause issues.

So I have two questions for @weaverryan and @Lyrkan:
(1) Is there any reason webpack can't be added as _both_ a dependency and a peer dependency for webpack-encore?
(2) What are the issues that may be caused by specifying webpack as a (dev) dependency of your own project? Why can they not co-exist?

Ultimately, the goal for a developer, set out in the blog post linked by the OP, is to not depend on a transitive dependency (that is, a dependency of your dependency), as it could change out from under you, or you could want to override it from above, or you could have other dependencies that have different requirements.

Leaving things as they are, it seems to me, is to actively discourage what is otherwise a best practice and undermine the benefits of dependency resolution.