Package-maintenance: discourage use of unmaintained packages

[boneskull]

This would be more of an "advocacy" or "lobbying" initiative.

Tools like npm and GitHub should perhaps actively discourage users from adopting unmaintained packages.

How such packages would be flagged is another problem, but a combination of crowdsourcing and analysis might work.

That said, I do want to limit the scope of the nodejs/package-maintenance initiative, and unless this is something others feel strongly about, I'd say our time is probably better spent on helping projects that want our help.

[ljharb]

I think answering the question "what constitutes an unmaintained package" is worth answering before any discouragement of an undefined category.

[boneskull]

• npm already has the "deprecate" command, but IMO it's way underused.
• npm audit is a thing and helps with packages having vulnerabilities.

For our purposes, though, maybe that could be limited to packages that do not support LTS versions of Node.js...

but yes, I agree, "what" is an unmaintained package should be answered before we get to the "how"

[ljharb]

Encouraging maintainers to npm deprecate versions with bugs seems like a great initiative tho.

[boneskull]

insofar as packages adopting "LTS", npm deprecate on all unmaintained release lines should be encouraged too

[wesleytodd]

Encouraging maintainers to npm deprecate versions with bugs

npm deprecate on all unmaintained release lines

These are both things I can get behind, and they can be semi-automated as well. If there is a tool which does this already we should promote it. I couldn't find any one, but this module leads me to believe @ljharb might be helpful to anyone who might want to write one. Seems like doing a cli which you could call from a postpublish script would be awesome, like $ deprecate --range="<3" where range could be passed to semver.satisfies.

[boneskull]

An npm RFC to provide this behavior via a publishConfig setting might also be worthwhile.

[mhdawson]

I agree this fits in the advocacy/standard practices side of things.

[mhdawson]

I think this fits well with the discussion in:

• https://github.com/nodejs/package-maintenance/issues/119#issuecomment-452064899
• https://github.com/nodejs/package-maintenance/issues/6

As a third dimension which adds information about specifics for each version

[hutson]

Hopefully the following is informative, and not taken as a self-promotion.

The company I work for has spent the past few years looking into how we can support our developers through better communication of package versions that are no longer supported (no back-ported patches, security patches, etc.).

From the perspective of a library developer, we feel it's important to communicate what they can reasonably support given the finite resources available (time, business objectives, human resources, etc.).

From the perspective of an application developer, we feel it's important to know whether the application is using a version that can be supported by the library developer (using an unsupported version is a risk to the availability of the application, and the application user's experience, should it be discovered that the library contains issues that cannot be resolved in a timely manner).

To improve our communications, nudge application teams to migrate to supported library versions, and reduce risk, we developed a tool (A GitHub App) to automate a deprecation policy.

deprecator - https://www.npmjs.com/package/deprecator

It's available as an opt-in App for our library teams. The App is configured with a default set of policy rules, though individual teams are welcome to deploy their own instance as needed to align with their business objectives.

[mhdawson]

@hutson thanks for the comment/info, helping to re-use the experience of what maintainers/consumers have already learned and are doing is one of the things we want to achieve.

[dominykas]

Some related RFCs on the npm side:

• https://github.com/npm/rfcs/pull/6
• https://github.com/npm/rfcs/pull/27 (replaces the above)

[mhdawson]

@jchip is taking a first cut at writing up a best practice for maintainers and guidance for consumers.

[Eomm]

Closing since it is landed with #150
Feel free to reopen if we miss some info