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 yarnpkg/yarn#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.

[0x7061]

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.

[mbrodala]

@GPHemsley-RELX As far as I understand if you have webpack both as dependency of @symfony/encore and in your own root package, you could technically get 2 different versions and they can diverge. Only if you constantly update your root version constraint to be in sync with any change in @symfony/encore you could be sure to have only 1 version.

Otherwise together with the package hoisting of NPM/Yarn it wouldn't be clear which of these 2 versions would end up toplevel in node_modules and thus used when invoking webpack as CLI command.

Please correct me if I'm wrong.

[mmarton]

One of my the oldest issue finally solved by release v4 :D