The URL used in the examples has some numbers in it that look like semver, yes. But Deno itself does not have any notion of semver; it does not have a tool that reconciles dependency versions based on version ranges like Node.js has (npm and npmjs.com).
Npm has algorithms that automate the process of handling version mismatches. Deno does not.
Any semver-related tooling that currently exists for Deno, is not official and not baked into the foundation of what Deno is in the way that NPM's version handling has been baked into the foundation of Node.js since the beginning with forethought of the problems it would solve.
In Deno, a developer is going to eventually indirectly import dependencies that are the same library, but from different URLs (maybe only the "semver" numbers in the URL will differ) and end up with unnecessary duplicates of the dependency with no clear way on how to handle the situation. That won't scale as well as an official versioning system would. GoLang has had the same problems.
I proposed in Deno's chat room that perhaps Deno's package registry (deno.land/x) should officially support semver in some way, similar to how unpkg.com has support for semver ranges, but the idea was taken lightly by the team (at least it didn't seem like something important to them).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The URL used in the examples has some numbers in it that look like semver, yes. But Deno itself does not have any notion of semver; it does not have a tool that reconciles dependency versions based on version ranges like Node.js has (npm and npmjs.com).
Npm has algorithms that automate the process of handling version mismatches. Deno does not.
Any semver-related tooling that currently exists for Deno, is not official and not baked into the foundation of what Deno is in the way that NPM's version handling has been baked into the foundation of Node.js since the beginning with forethought of the problems it would solve.
In Deno, a developer is going to eventually indirectly import dependencies that are the same library, but from different URLs (maybe only the "semver" numbers in the URL will differ) and end up with unnecessary duplicates of the dependency with no clear way on how to handle the situation. That won't scale as well as an official versioning system would. GoLang has had the same problems.
I proposed in Deno's chat room that perhaps Deno's package registry (deno.land/x) should officially support semver in some way, similar to how unpkg.com has support for semver ranges, but the idea was taken lightly by the team (at least it didn't seem like something important to them).