[1] https://deno.land/manual/linking_to_external_code [2] https://github.com/denoland/deno/discussions/11809#discussio...
[1] https://deno.land/manual/linking_to_external_code [2] https://github.com/denoland/deno/discussions/11809#discussio...
[1]: https://deno.land/manual@v1.13.1/linking_to_external_code/im...
That requires that you know every way that conceptually the same packages are imported in the entire transitive module graph, which is hard enough on its own, but also requires crawling the whole live module graph to discover all the imports. I don't see how this isn't just npm-but-worse.
Without bare module specifiers (like `import {html} from 'lit-html'`) to act as an abstraction over location you have to import directly from a URL, but what URL? Packages either have to be self-hosted, or very often npm packages are loaded via CDNs. There are several CDNs that host the same packages (unpkg, Skypack, jspm, jsDelivr/esm.run) so there's no single canonical URL to load anything from and each module that loads a package could load from a different CDN, or simply load a slightly different but compatible version, causing multiple copies of the packages to be loaded.
There's a huge benefit to abstracting over package names, and Deno mostly throws it all away. It does support import maps, but you'd need tooling that doesn't fully exist yet to crawl and dedupe a module graph and at that point it'd basically be npm but a lot slower with no registry to use for metadata.
That's a rather subjective take.
The rest of your comment can be fulfilled by `trex` https://nicedoc.io/crewdevio/Trex. Perhaps it's been a while since you took a good look at how the ecosystem has evolved. I just started giving Deno a hard look last week and I've already found answers for needs like this.
Trex doesn't do anything about transitive dependencies and package deduplication, what my critique is about.
This is kind of like saying "Oh it supports Javascript? So now I'm tied to Netscape's take on browser scripting?" at this point. Typescript has won the JS compiler wars and become the defacto standard for the community.
edit to add: I'm serious. JavaScript tries very hard to not have backward breaking changes. TypeScript does have breaking changes at about ever minor release. The TypeScript team manages the project as a versioned tool, not as a distributed environment like the web. afaik, Deno hasn't really solved this problem, so there's a chance your code breaks when Deno upgrades its TypeScript version.
Even so, they could limit such breakage to major Deno versions with other breaking changes, if necessary. Not sure if they do.