TypeError: Invalid major version

[sentry-io]

Sentry Issue: CRATES-IO-FRONTEND-P2

TypeError: Invalid major version
  at new c (addon-tree-output/~ember-css-modules/ext.js:2:1)
  at e.exports (addon-tree-output/~ember-css-modules/ext.js:2:1)
  at None (addon-tree-output/~ember-css-modules/ext.js:2:1)
  at Array.sort (<anonymous>)
  at default (addon-tree-output/~ember-css-modules/ext.js:2:1)
...
(19 additional frame(s) were not displayed)

[Turbo87]

the relevant link here is https://crates.io/crates/test-max-version-example-crate/18446744073709551615.18446744073709551615.18446744073709551615 ....... 🙈

[plaets]

I can't reproduce it...
It could be is caused by #3246, semver is (explicitly) packaged since then
Relevant lines:
https://github.com/npm/node-semver/blob/e08d9167937e09e8e6fe23aacaf17f892a1d69e1/classes/semver.js#L48
https://github.com/npm/node-semver/blob/e08d9167937e09e8e6fe23aacaf17f892a1d69e1/internal/constants.js#L6
Edit: although the downloads chart is not rendered on https://crates.io/crates/test-max-version-example-crate/

[Turbo87]

I think the problem is that the version number is too large for the JS-based semver parser, but the Rust-based semver parser allows it. I guess we might have to code defensively here and expect the JS-based parser to fail in a few edge cases.

[plaets]

Should we replace node-semver with something that uses BigInt for the version numbers? Or maybe let this one case slip and implement a max version number limit in the backend, so that crates like that are rejected during publishing?
Edit: Or I guess we could also just catch this exception

[Turbo87]

Or I guess we could also just catch this exception

yeah, I guess that might be the easiest. in case the sorting fails we'll just continue without explicitly sorting. in other words: we can wrap the sort call with a try/catch, with an empty catch block, ideally with a code comment inside that explains why we ignore the error.