We need to distinguish between npm, the service (https://www.npmjs.com/ https://www.npmjs.com/) and npm, the tool. Deno has the functionality of npm, the tool,

We need to distinguish between npm, the service (https://www.npmjs.com/ https://www.npmjs.com/) and npm, the tool. Deno has the functionality of npm, the tool, built-in. The difference is that like Go, Deno imports the code directly from the source repository. In practice it's going to be github.com (but can be gitlab or any code hosting that you, the author of Deno module, use). NPM is a un-necessary layer that both Go and Deno has removed. It's better because it's simpler for everyone involved. In Go, I don't need to "publish" my library. People can just import the latest version or, if they want reproducibility, an explicit git revision. Compared to Go, publishing to npm is just unnecessary busy work. I've seen JavaScript libraries where every other commit is related to publishing a new version to npm, littering the commit history. In Go there's no need for package.json, which mostly replicates the information that was lost when publishing to npm (who's the author? what's the license? where's the actual source repository?). As to this being insecure: we have over 10 years of experience in Go ecosystem that shows that in practice it works just fine.