Update: mithril v2.2.3 has been deprecated, v2.2.2 is the current version

[pygy]

Library name

mithril

Library JSON file

https://github.com/cdnjs/packages/blob/master/packages/m/mithril.json

Library source

https://www.npmjs.com/package/mithril

Files to include

mithril.js mithril.min.js mithril.min.js.map stream/stream.js

[MattIPv4]

👋 It is not possible for us to remove existing versions on the CDN -- once they are published, they are immutable and must remain unchanged forever to ensure we don't break any websites that may have started using the assets.

[pygy]

No problem re. deletion, but could https://cdnjs.com/libraries/mithril point to v2.2.2 rather than v2.2.3?

It is confusing for some users.

[MattIPv4]

Unfortunately, no, it's not possible to manually override what version that displays -- it will always display the most recent version based on semver sorting

[pygy]

Would you accept a PR that displays the latest version available on NPM rather than the last version you have?

[MattIPv4]

No -- there is no guarantee that the latest version on NPM matches the latest version that our automation has pushed to the CDN (nor are all libraries on cdnjs driven by NPM packages)

[MattIPv4]

Just to tie the issues together, #926 + #1289 + #1307 are all issues around hiding versions that were accidentally published and pushed to the CDN

[pygy]

> there is no guarantee that the latest version on NPM matches the latest version that our automation has pushed to the CDN

I'm not following... NPM does provide a canonical latest version, it even looks like your npm regsitry handler returns it already.

https://github.com/cdnjs/tools/blob/2b7cddcb99cae64fca46a0703e548750c7d096c7/npm/registry.go#L97

I know you currently don't provide the guarantee that the versions are matched, that's why I'm here in the first place... What I don't get is why it can't be matched when it seems to be in the realm of possible things.

I understand this can't be generalized to each and every package source, and that handling the cases that can't be automated would be bothersome, but here it would be a net improvement.

[MattIPv4]

My concern would be the case where NPM says the latest version is a version that cdnjs does not have.

Say x and y have been published to NPM, with y being "latest", but cdnjs has neither. If we were to process x and then use NPM to determine the latest, we'd end up saying y is latest when we don't have it. Once when then process y though, at that point we could use that as latest. Equally, if "latest" on NPM gets set to an older version that cdnjs simply doesn't have (if a library gets added/updated, we only pull in the 10 most recent releases), then we couldn't rely on this either.

If the logic can be written in such a way that it handles that though, and only uses the NPM "latest" if that's actually a version that cdnjs has, seems like a safe add.

(My only other note would be that I can't guarantee any changes to that repo will be merged/accepted, that repo is maintained by folks at Cloudflare who have been rather unresponsive to issues for a while now)

[pygy]

Pointing to npm's @latest when it is available on your servers would seem reasonable, yes!

Pointing latest more than 10 versions in the past must be quite rare, so the above would fix most botched releases.