Dependency locking can cause multiple versions of slonik to be installed

[nonara]

Problem Detail

This package specifies a major pinned dependency of slonik. In the case of using the latest major version to accompany it, it will result in two instances of slonik being installed. One as a dependency of this addon and another for the main package.

This is especially prone to causing problems in the case of mono-repo. Consider the following example:

• core/
  • package.json
    • slonik 23.x,
    • slonik-interceptor-query-logging
      • slonik 22.x
• package2/
  • peerDependencies: core + slonik

In this case, using yarn workspaces, require('slonik') in core will get v23, but package2 and anything else in the monorepo ends up getting v22. This problem can be difficult to debug, because when trying to compare errors, you end up with issues like NotFoundError !== NotFoundError due to separate packages.

One remedy on our end would be to manually repeat the slonik version in every package which requires it, but this method requires that we be diligent about maintaining each. Inevitably, someone ends up forgetting and we lose time tracking down issues that end up being a multiple slonik versions issue.

Solution

In cases like these, where the library is intended to be an accompaniment to another that is already installed, using peerDependencies is the preferred route.

Generally speaking, it's not advantageous for your helper library to use a different version than the library its meant to augment. Using peerDependencies mitigates that issue.

I'll submit a PR. Let me know if you have any questions.

[gajus]

🎉 This issue has been resolved in version 1.3.9 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀