QuiiBz / sherif

Opinionated, zero-config linter for JavaScript monorepos
MIT License
783 stars 11 forks source link

Skip multiple-dependency-versions rule in packages with peerDeps and devDeps #89

Open alSergey opened 3 weeks ago

alSergey commented 3 weeks ago

Thanks a lot for the linter, I really liked the multiple-dependency-versions rule. I haven't seen anything like it anywhere else.

Reproduction

https://stackblitz.com/edit/sherif-peer-dev-deps?file=package.json

Information

When you develop a package, you want to specify a lower version in peerDependencies so that users have more freedom. In order to test your package on this version, you add exactly the same dependency to devDependencies.

At the same time, you want to use a newer version in the repository itself. This is where the problem arises in the multiple-dependency-versions rule.

Expected behavior

Linter doesn't complain about the fact that I have different versions of @playwright/test installed in the root and in the package

Actual behavior

Linter complains that I have different versions of @playwright/test installed in the root and in the package

image

Additional information

The @manypkg/cli linter has a rule on this very topic.

QuiiBz commented 3 weeks ago

Thanks for the repro!

At the same time, you want to use a newer version in the repository itself. This is where the problem arises in the multiple-dependency-versions rule.

I think the fix for this use-case is to ignore the dependency that has a lower version and the peer dependency (you need sherif@0.11.0), so that you keep the multiple-dependency-versions rule active for the rest of your monorepo. In your repro, this would be:

sherif -i @playwright/test@1.37.0

Does that help?

alSergey commented 3 weeks ago

@QuiiBz hi, I already have it set up as you suggested and everything works. But I would like to have a more correct solution for this problem. In another repository I have 5 such packages and I have to add them all to ignore. It would be cool if the linter took such cases into account.

QuiiBz commented 3 weeks ago

It might be possible to infer it and automatically ignore a dependency in a specific package if we also detect a peer dependency for it (aka automating what we just described above) - will need to thing a bit more about it to make sure it doesn't have any drawbacks.