Implement Package Staleness and Stability Flags on pub.dev

[stan-at-work]

Description:
To improve the overall health and quality of packages on pub.dev, I propose the following enhancements to encourage developers to maintain and update their packages regularly:

1. Stale Package Warning:

• Packages that haven't been updated for a specified period (e.g., 6 months or 1 year) should be flagged with a "stale" warning.
• Developers could have the option to mark packages as intentionally stable or inactive, which would exempt them from the stale warning if they are genuinely meant to be "set and forget."

2. SEO Ranking Impact:

• Packages flagged as "stale" or "not maintained" should have their visibility and ranking lowered in search results on pub.dev.
• This would encourage developers to keep their packages up-to-date with the latest standards.

3. Automatic pub get Validation:

• On every package upload and on a daily basis, pub.dev should run pub get for each package to ensure it can still be properly installed and resolved.
• If pub get fails due to errors or dependency conflicts, a warning should be displayed on the package page, such as "This package is currently unstable due to dependency resolution issues."
• Developers should be notified of these issues and given guidance on how to resolve them.

---

Benefits:

• Improved Package Maintenance: Encourages developers to keep their packages updated and aligned with current standards, reducing technical debt and dependency issues for users.
• Clearer Information for Users: Helps package consumers make informed decisions by clearly indicating which packages are actively maintained and which may pose risks.
• Quality Assurance: By running pub get daily, we can catch issues proactively before users report them, leading to a more stable and reliable ecosystem.

---

Possible Next Steps:

1. Discuss feasibility and potential impact with the Dart and Flutter teams.
2. Implement a system to track package update history and flag stale packages.
3. Integrate pub get validation into the package publishing process.

[isoos]

Packages that haven't been updated for a specified period (e.g., 6 months or 1 year) should be flagged with a "stale" warning.

We've considered this multiple times over the past 8+ years, but time and again it turns out that it may make sense in some cases, it doesn't make sense as a general rule. Take, for example, package:retry https://pub.dev/packages/retry it hasn't seen any new release in the past 19 months, and it still good and kicking. It does its job. There is no reason to penalize it for not releasing.

Developers could have the option to mark packages as intentionally stable or inactive.

This is the discontinued setting that one can set at the package admin page.

Automatic pub get Validation

It is already part of our package analysis checks whether a package can be pub get, or if it has its dependencies setup correctly (including lower bounds), or if after a successful resolution it gets a clean static code analysis. If we aren't covering most of the stuff already that you've mentioned, please file an issue on https://github.com/dart-lang/pana about it.

Do you have any specific package as an example that we are failing our analysis on?

[stan-at-work]

Do you have any specific package in mind where our analysis is failing?

No, not specifically.

Our package analysis already checks whether a package can run pub get, if its dependencies are correctly set up (including lower bounds), and if, after a successful resolution, it passes a clean static code analysis. If we are not covering most of the points you've mentioned, please file an issue on https://github.com/dart-lang/pana.

Does this also occur when a new Flutter release is introduced? That’s when problems tend to surface.

We’ve revisited this idea several times over the past 8+ years. However, it consistently turns out that while it may make sense in certain cases, it doesn't hold as a general rule. Take, for instance, package:retry (https://pub.dev/packages/retry). It hasn’t seen a new release in the past 19 months, but it’s still functional and doing its job. There’s no reason to penalize it for not releasing.

True… But I would make exceptions for those cases. There are far more poorly maintained packages than good ones. Developers should be able to submit a request to you, explaining why the constraint should not apply to their package. However, it would still be beneficial for the other packages, especially those without a large user base — the 95% of remaining packages.

[isoos]

Does this also occur when a new Flutter release is introduced? That’s when problems tend to surface.

Yes, we re-analyze package every now and then, at latest about once a month (if it was successful last time), and also when a package's dependency is updated, also when we release a new site version that has new analysis elements. In practice we re-analyze the latest version of a package weekly on average.

There are far more poorly maintained packages than good ones.

Maybe, but the release date, release frequency or similar metrics seem to be a poor proxy for that.

Developers should be able to submit a request to you, explaining why the constraint should not apply to their package.

In practice, if your dependencies are out of date, it will be shown in your analysis scores, as we have various metrics that will expose bad constraints. See more about it on https://pub.dev/help/scoring

And also, please, if you see some package that is wrong in a measurable, analytical way, open an issue about it here or in pana's repository. We should investigate and consider new metrics if we see something off.

[jonasfj]

We are discussing a lot of things in this issue. So please do consider splitting into separate issues.

Overall, yes, there is a lot of outdated packages, this is a common problem in many ecosystems. That doesn't mean we shouldn't do something about it, just that's it really hard.

---

Disclaimer: I wrote package:retry, so the following example may be biased 🤣

Package retry is a good example:

• It doesn't need many updates
• It doesn't have many dependencies.
• It's a useful package.
• It has a stable API.
• It has good documentation.
• It does one thing and it does it well.

All these things are good properties for a dependency. IMO, if you're writing an application you an choose to write your own retry logic, it's not that hard. But it's easy to be off by one, boring to write tests and you might have to think to do exponential back-off.

My point is: The fact that package:retry isn't updated frequent is what makes it a good dependency.

If package:retry had an implementation that was deeply interwoven with other packages/SDKs and needed to be patched frequently. Then you should definitely just write your own retry-logic.

---

True… But I would make exceptions for those cases. There are far more poorly maintained packages than good ones.
Developers should be able to submit a request to you, explaining why the constraint should not apply to their package.

The default should be a that a package, if useful once published, shouldn't need to be patched constantly.

And if it breaks we should be able to detect it with pana.

With SDKs (both Flutter and the underlying OS SDKs) moving fast, and sometimes breaking things, that can arguably be hard. And it is hard to avoid breaking things, if a breakage unlock additional size reduction, I can see how it's attractive.
And underlying changes in the OS SDK can be hard for pana to detect.

I wonder though, is this much of a problem for packages that don't rely on Flutter or plugins directly or indirectly?

I'm not sure I have an answer. I agree that the option to mark a package discontinued doesn't work well, because maintainers usually don't decide to stop maintaining something. Most of the time, they just gradually stop, loose interest or spend their time on something else.

Having a way for someone other than the package author to label a package as "discontinued", would be attractive. But I'm not sure who or how.

---

It's is possible that packages which fail dart pub get && dart analyze should be removed from search if not patched within 90 days. Or something like that. But it's not trivial.

We have important packages failing dart pub get && dart analyze because they target a beta SDK, etc. I think we fixed most edge cases, but probably not all.

[stan-at-work]

It's is possible that packages which fail dart pub get && dart analyze should be removed from search if not patched within 90 days. Or something like that. But it's not trivial.

I believe this could significantly improve the integrity of many packages. In my opinion, an author should not upload a package if they cannot maintain it.

Additionally, it might be a good idea to only accept verified publishers moving forward. Publishers could be required to validate their email and website. While I understand that not every package has a website, I think setting up some limitations could enhance the overall quality of the packages.

Sometimes, less is more.

---

To further improve the ecosystem, packages that fully support the Flutter ecosystem—such as Flutter mobile, desktop, and web—could be ranked higher in search engine results.

[isoos]

I believe this could significantly improve the integrity of many packages. In my opinion, an author should not upload a package if they cannot maintain it.

Strongly disagree about this one. There may be value in packages that are not maintained, but may be later picked up by others (either by forking or ownership takeover), and keeping them as part of search is an important step for that. Having said that, we should downrank such packages, which, through the points we already do (e.g. a failed pub get will lose a lot of points).

To further improve the ecosystem, packages that fully support the Flutter ecosystem—such as Flutter mobile, desktop, and web—could be ranked higher in search engine results.

Disagreeing here again: there is a good value in a web-only or a desktop-only package. It may not be for everyone, but that doesn't mean the package is useless.

Edit: Years ago we've had an additional ranking in search which was based on the filters, e.g. if you have filtered for web packages, it ranked web-only a slightly bit higher than the rest (assuming that you are interested in web-only packages). It turned out to be not a good ranking rule, and having an equal ranking regardless of the platforms seems to provide better results now.

Additionally, it might be a good idea to only accept verified publishers moving forward. Publishers could be required to validate their email and website. While I understand that not every package has a website, I think setting up some limitations could enhance the overall quality of the packages.

Users of the site need a valid Google account, we can assume it is validated if they can use that. You can already see if a package has a verified publisher (aka. domain name), and use it to gain more insight. It certainly increases trust, but doesn't necessarily translates to quality immediately.