Repository navigation
discourage use of unmaintained packages #93
Description
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.
Reacted by Paul Melnikow
Metadata
Metadata
Assignees
Labels
No labels
Activity
ljharb commentedon Dec 13, 2018
I think answering the question "what constitutes an unmaintained package" is worth answering before any discouragement of an undefined category.
boneskull commentedon Dec 13, 2018
npmalready has the "deprecate" command, but IMO it's way underused.npm auditis 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 commentedon Dec 13, 2018
Encouraging maintainers to
npm deprecateversions with bugs seems like a great initiative tho.boneskull commentedon Dec 13, 2018
insofar as packages adopting "LTS",
npm deprecateon all unmaintained release lines should be encouraged toowesleytodd commentedon Dec 15, 2018
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
postpublishscript would be awesome, like$ deprecate --range="<3"whererangecould be passed tosemver.satisfies.boneskull commentedon Dec 16, 2018
An npm RFC to provide this behavior via a
publishConfigsetting might also be worthwhile.mhdawson commentedon Dec 20, 2018
I agree this fits in the advocacy/standard practices side of things.
mhdawson commentedon Jan 7, 2019
I think this fits well with the discussion in:
As a third dimension which adds information about specifics for each version
hutson commentedon Jan 8, 2019
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/deprecatorIt'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 commentedon Jan 9, 2019
@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 commentedon Jan 14, 2019
Some related RFCs on the npm side:
mhdawson commentedon Feb 25, 2019
@jchip is taking a first cut at writing up a best practice for maintainers and guidance for consumers.
Eomm commentedon Aug 31, 2019
Closing since it is landed with #150
Feel free to reopen if we miss some info