Also Deno has a command line fallback for its version of GOPATH, which is smart because it turns out a huge percentage of devs don’t know what env vars are or how to set them.
But other than cosmetic differences, it’s pretty much identical to Go.
This gave me a laugh but it’s not fair! I’d guess most of the GOPATH outcry was the annoyance around managing automated and other non-dev environments.
GOPATH was nothing short of a monstrosity. Its problems were truly obvious on day 1, but it lingered and infected everything.
Deno directly use standard URIs to import packages. Go imports syntactically appear as schemeless paths, which boils down to the semantics of importing URIs from an implicit private go:// scheme.
And that catches two fishes at once:
1) the go:// namespace is isomorphic to the https:// namespace, so the default resolution strategy is just to pipe through this isomorphism. This is convenient, makes sense right away and avoids the a priori need of a central registry.
2) Whenever it's needed, the resolution can be instructed to do some custom thing instead of casting to https://.
The exemplar instance of 2) is the usage of sibling packages. They wanted to make it possible to have several packages within a single module, whereby the module serves as a compilation unit. So when an import path is a subpath of the module path, then the package is looked up locally, relative from the root of the current module. There is no way you could get away with such a bending of a https:// URI. But go:// being a private scheme gives the freedom to proceed so.
(The go:// scheme is just my own literary device, but this semantics is explained clearly in simple terms at https://golang.org/doc/code.html.)
> deno run --allow-write=~/only-evil-here http://dangerous.com/evil.ts