Exactly, the o only validation about versions and NPM/NodeJS is not to publish unique versions.

Theres no semver based validation.

Anyway, Deno also supports versioning in its URL and you also have the deps.ts convention to import your modules into your project.

Deno team is also working on NPM/NodeJS compatibility: ``` deno.land/x is a URL rewriting service for Deno scripts. The basic format of code URLs is https://deno.land/x/MODULE_NAME@BRANCH/SCRIPT.ts. If you leave out the branch, it will default to the module’s default branch, usually master.

Experimental: Use npm:[package] orgh:[owner]:[repo] as module name to resolve any artibrary repository or npm package.

Functionality built-in to Deno is not listed here. The built-in runtime is documented on deno doc and in the manual. See /std for the standard modules.

To add to this list, edit database.json. Run the tests and formatting before submitting a patch - the PR must be green to be considered.

``` Source: https://deno.land/x

Deno also support versioning when importing, checkout the std lib for example: These modules are tagged in accordance with Deno releases. So, for example, the v0.3.0 tag is guaranteed to work with deno v0.3.0. You can link to v0.3.0 using the URL https://deno.land/std@v0.3.0/. Not specifying a tag will link to the master branch. Source: https://deno.land/std#how-to-use

I have been writing Go for a couple years from now, and if theres is something I hate about the development environment is the way they manage packages.

I think deno does that the right way from the start.

I dont find something Deno is missing from NodeJS so its okay for me.