When a PR is closed, merged or not, the releases made, if any, for commits in that PR, and the PR dist-tag itself, if any, should be cleaned up.
How
With $ dripip get-version-for-commit we already know how to fetch all the releases for a given PR. What's needed is new logic that would iterate through each found version, deprecating it on the npm registry.
Why
PR releases can add a lot of pre-release versions to a package history. They are useful for agile reasons but they are not interesting long-term. As such, if left unchecked, they stand to add significant noise to the package version history, making it harder to review it.
Also, if left unchecked, the results from npm view <package> <versions>, which lists ALL versions of a package EVER, will grow larger much faster, potentially creating latency or other problems with flows relying on this information, dripip certainly but also other tools, if any.
What
When a PR is closed, merged or not, the releases made, if any, for commits in that PR, and the PR dist-tag itself, if any, should be cleaned up.
How
With
$ dripip get-version-for-commitwe already know how to fetch all the releases for a given PR. What's needed is new logic that would iterate through each found version, deprecating it on thenpmregistry.Why
PR releases can add a lot of pre-release versions to a package history. They are useful for agile reasons but they are not interesting long-term. As such, if left unchecked, they stand to add significant noise to the package version history, making it harder to review it.
Also, if left unchecked, the results from
npm view <package> <versions>, which lists ALL versions of a package EVER, will grow larger much faster, potentially creating latency or other problems with flows relying on this information, dripip certainly but also other tools, if any.