-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
discourage use of unmaintained packages #93
Comments
I think answering the question "what constitutes an unmaintained package" is worth answering before any discouragement of an undefined category. |
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" |
Encouraging maintainers to |
insofar as packages adopting "LTS", |
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 |
An npm RFC to provide this behavior via a |
I agree this fits in the advocacy/standard practices side of things. |
I think this fits well with the discussion in:
As a third dimension which adds information about specifics for each version |
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.
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. |
@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. |
Some related RFCs on the npm side:
|
@jchip is taking a first cut at writing up a best practice for maintainers and guidance for consumers. |
Closing since it is landed with #150 |
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.The text was updated successfully, but these errors were encountered: