It feels broken, because it's a bad idea, per the design itself. Basically, you're ("you" as in figuratively speaking) smashing the functionality of a package

It feels broken, because it's a bad idea, per the design itself. Basically, you're ("you" as in figuratively speaking) smashing the functionality of a package manager into the interpreter. I'm not convinced at all that making a single tool do more and more stuff is a good idea, but let's keep on. Then, you're writing URLs (for the libraries you're importing) all over the code (which is just bad). Deno's solution (from the link in my prev reply) is to just put all the URLs in a single file (so, basically a "packages.json", but now inside your code, ¿because that's somehow a good idea?). Then there's the entire thing about replacing NPMJS, which has full-time engineers working on security, maintenance, etc... with a bunch of different servers, maybe maintained, maybe not, by random people. Then there's the entire "but how can I be sure that the code didn't change?" thing, to which Deno suggests to use a "--lock command flag". This sounds like "npm.lock / yarn.lock". And finally, there's the availability concern ("what happens if any of these servers goes down?"), which Deno just dismisses by saying that this can happen to any server. And while that is technically true, pulling all your dependencies from a single place, instead of N different places, reduces the points of failure to 1 (instead of N). So, this entire "import directly from URLs" sounds just like a package manager with different steps, without providing anything new, without fixing any specific problems with package managers, and introducing new problems (which are in fact old problem, because as I said, we've been there already when PHP thought remote includes were a good idea).