Deno doesn't have official semver support. I can only imagine the headaches that will happen on large Deno applications. Semver reduces problems. Deno is behind in that regard (similar to Go). Sure some people are trying to make semver tools, but these are community-based and non-standard, so things will be fragmented within Deno in terms of dependency management.
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.
Deno doesn't have official semver support. I can only imagine the headaches that will happen on large Deno applications. Semver reduces problems. Deno is behind in that regard (similar to Go). Sure some people are trying to make semver tools, but these are community-based and non-standard, so things will be fragmented within Deno in terms of dependency management.
The example literally showed semver being used, I have no idea what you have against deno.
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).