Move MongoDB to peerDependencies

[rtritto]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Fastify version

4.14.1

Plugin version

6.2.0

Node.js version

16

Operating system

Windows

Operating system version (i.e. 20.04, 11.3, 10)

11

Description

MongoDB should be moved from dependencies to peerDependencies

Expected Behavior

No response

[climba03003]

I am pretty much against the usage of peerDependencies.
But open to made changes if others agree.

[Uzlopak]

I would prefer to put it into peerDependencies when node14 is deprecated and all supported node versions use npm version >= 7, which ensures that the peerDependencies exist by downloading them. Npm 6 in node 14 does not download the peerDependencies....

[jsumners]

Peer dependencies are nothing but trouble. Particularly with the way they keep getting handled differently with seemingly every new npm release.

[mcollina]

I'm sincerely -1. They cause more problems than they are worth.

Note that they would not give you any real benefits over a production dependency, because we would not specify a multi-major range.

[rtritto]

With no peerDependency, the dependency version can't be chosen (eg: use a specific version in case of bugs).
I think that Fastify plugins should only "connect" and use dependencies where they are installed. Eg: this plugin should have fastify and mongodb as peerDependencies, by this way there is a single instance of both and there are no duplicates for installed libraries in dependencies tree.

Some sources:

• Using peer dependencies
• Understanding peer dependencies in JavaScript

[rtritto]

@mcollina

Note that they would not give you any real benefits over a production dependency, because we would not specify a multi-major range.

Eg: having v4 and v5, we have these use cases:

1. minimum version:

"peerDependencies": {
  "mongodb": "^4.1.2"  // random version of 4 --> version needed is >= 4.1.2
}

2. major version (use only 1 version because they have breaking changes)

"peerDependencies": {
  "mongodb": "^4"  // support only version 4 --> version needed is one of 4
}

or

"peerDependencies": {
  "mongodb": "^5"  // support only version 5 --> version needed is one of 5
}

3. multiple versions

"peerDependencies": {
  "mongodb": "^4 || ^5"  // support both versions --> version needed is 4 or 5 (handle breaking changes in code if they are needed)
}

[mcollina]

Maintaining support for multiple versions and handling the breaking changes in the codebase is a (deliberate) non-goal. Maintaining those kind of support matrix is extremely hard, considering all the wrappers there are in this organization.

All the other three versions have no benefit compared to equivalent versions for normal dependencies. All package managers correctly deduplicate those.

[rtritto]

Maintaining support for multiple versions and handling the breaking changes in the codebase is a (deliberate) non-goal.

I know, it's advised to update and use only latest (v5).

[rtritto]

All the other three versions have no benefit compared to equivalent versions for normal dependencies. All package managers correctly deduplicate those.

Main problem is with multiple context (instance).

From Using peer dependencies:

Though, more importantly, a peer dependency is more resilient to issues in runtimes. This is particularly important for libraries that use React context like MDX and even Emotion.

If a library specifies its own version of React/MDX/Emotion/etc. it can end up with multiple versions on the client. This will cause conflicts with React, where context will disappear.

Understanding peer dependencies in JavaScript

Examples of when you want to use peerDependencies are:
Express middleware packages: This is just one example of an NPM module that would require the use of peer dependencies. You’d want to declare express as a dependency, just not a hard one, otherwise, every middleware would install the entire framework each time.

If peerDependencies are used like a standard, there should be less headaches.

[rtritto]

All package managers correctly deduplicate those.

This use case can't be deduped:

├── mongodb 4.1.0 (same level of @fastify/mongodb)
└─┬ @fastify/mongodb
  └── mongodb ^4.2.0-latest (dependency of @fastify/mongodb)

[mcollina]

We should not support or facilitate using old and buggy software versions that should not include breaking changes.

In my experience, peer dependencies are a major headache to maintain.

[rtritto]

We should not support or facilitate using old and buggy software versions that should not include breaking changes.

Of course, but with that use case, when you install this plugin, you have no info (it's silent with any warning message or alert) or control that different versions of same dependency are installed.

Please, can you write the headaches to mantain peer dependencies?

Note: I think that this issue should remain opened or, at least, it should be converted in a discussion.

[jsumners]

I have had very hard to debug and resolve issues around the mysql peer dependency in knex. The only resolution was to force npm to install with its legacy algorithms such that knex could find what it was looking for.

[rtritto]

I think that every project is different (unique) and the improvements can be (re)considered because times change.

[rtritto]

Is there anyone who can reconsider?