Dependency on *-loader implies a peer dependency on webpack

[chancancode]

I'm opening this issue so I have something to like to from my PR to ignore the missing peer dependency warnings on webpack in a v2 addon. As far as I can tell there isn't an existing issue for this, but it's a Known Problem™.

TL;DR for now you probably need:

{
  "pnpm": {
    "peerDependencyRules": {
      "ignoreMissing": [
        "webpack"
      ]
    }
  }
}

...in your package.json. However, this only works when set in the workspace root.

---

I'm probably not getting all the details exactly right, but it seems like we have a situation where we ended up with an undesirable peer dependency on webpack.

• ember-auto-import depends on...
  • babel-loader, css-loader, style-loader, mini-css-extract-plugin, which..
    • has a peer dependency on webpack

This is probably fair game for the original purpose of this package. The problem is that ember-auto-import has kind of evolved to take on a secondary role as a shim package, in that it provides a subset of Embroider's functionality to addons under the classic build, and when consumed inside an Emboirder build, this more or less just serves as a marker for Emboirder.

This creates a situation where a lot of addons, including ember-source, declares a runtime dependency on this package, which in turns pulls in and hoist the transitive webpack peer dependency to the end-consumer package.

This in turns means that, in situations where the consumers isn't using webpack (e.g. in an app with a vite build, or in a v2 addon that uses rollup), you end up with either a missing peer dependency warning or end up installing webpack as a dev dependency for no reason at all. It's also made a bit worse by pnpm workspaces, because you can only ignore peer dependency warning from the the root, not on a per-package level.

I suppose this was fine and probably understandable during the transitory period, but I am wondering what is the endgame here?

• Should this package be phased out and we expect the ecosystem to shed their dependency on this package soon, which makes the problem go away? To me this feels unlikely to happen soon/quickly, and there are legitimate reasons for the dependency.
• Should ecosystem packages be declaring this as an optional dependency? I suppose that could work, and is semantically valid in a sense (if you are using this addon in a classic build, then you need e-a-i version X), but it will probably degrade experiences for classic consumer quite significantly and may cause hard to understand issues?
• Or should this package try to absorb the problem, accept the fact that it has this dual purpose (and perhaps increasingly, its primary purpose) as a no-op "marker" package, and make those optional runtime dependencies, and throw runtime errors if they are needed but not installed? This seems like the least painful option for everyone.

I am not sure if those suggestions really makes sense, I'm just spitballing here. But regardless of solutions, I think we do have a real issue (perhaps a "well-known" one in the inner circle) that needs to be solved.

[Techn1x]

This was helpful to me, thanks. My vite v2 app was complaining about missing webpack for similar reasons

[mansona]

I imagine now that a Vite app doesn't need ember-auto-import since #670 this is no longer a problem?