search

salsify / ember-cli-dependency-lint

Lint your app's addon dependencies, making sure you only have one version of each.
MIT License
83 stars 8 forks source link

Specify allowed transitive dependencies #17

Open davewasmer opened 5 years ago

davewasmer commented 5 years ago

First off, great addon!

A quick suggestion: it would be nice to be able to specify allowed versions for specific transitive dependencies.

My concrete use case:

I'm using ember-cli-addon-docs, which right now is bringing in two copies of ember-cli-clipboard. I don't particularly mind if the addon docs load two copies of the clipboard addon - it's an internal use docs site, not worth the time right now to resolve that conflict.

However ...

If someone else down the road happens to install ember-cli-clipboard directly, or another addon that uses it, I definitely do want to know about conflicts then, because that copy may end up duplicated in the production app.

So really, what I want to be able to say is something like:

allowedVersions: {
  // Allow any version of ember-cli-clipboard *underneath* ember-cli-addon-docs
  'ember-cli-addon-docs ember-cli-clipboard': '*'

I could even imagine a little CSS-like microsyntax to specify different kinds of nesting (i.e. addon-a > addon-b would only apply to addon-b when it's a direct dep of addon-a) but that might be overkill.

Happy to take a stab at a PR when I have some spare cycles, but wanted to get feedback on the concept first.

Turbo87 commented 5 years ago

this sounds like it defeats the purpose of the addon. having multiple copies of the addon in the build is a real issue and not something that should just be ignored because it's "only a dummy app". the allowedVersions property is meant for build-time addons that do not add any incompatible files/modules to your project.

davewasmer commented 5 years ago

I realize that in an ideal world, even your dummy app wouldn't have duplicated versions of addons.

But unfortunately, sometimes other things take priority, and we simply don't have time to resolve that issue. But I'd still like to know when I duplicate an addon in the user-facing build.

To frame this another way, imagine the following setup:

my-app/
  lodash @ 2
  complicated-auth/
    lodash @ 1

I have duplicated lodash addons and I get the failed test, as expected.

Now imagine that complicated-auth is a third party lib, so I submit a PR to bump their version of lodash, but it isn't merged right away. My only remaining option to get my build passing in the meantime is to completely ignore all duplicated versions of lodash.

But now let's imagine another dev on my team adds decomposing-helpers:

my-app/
  lodash @ 2
  complicated-auth/
    lodash @ 1
  decomposing-helpers/
    lodash @ 1.2

I now have 3 versions of lodash, but don't realize it because I had to allowVersions for lodash.

I potentially could have even bumped the decomposing-helpers version of lodash (perhaps I control decomposing-helpers, or the maintainers are more responsive), but because I'm not aware of it, I don't do anything.

I think ultimately this is a balance between a pure, ideal solution (immediately fix all duplicated addons) and recognizing the unfortunate tradeoffs that teams sometimes face. I worry that saying "well you should never have this and ember-cli-dependency-lint will force you to fix it right away" will lead to more folks simply uninstalling dependency-lint or ignoring it's output.