Deno: Package aliases

[bahdcoder]

I've been building an entire application to get my hands wet with deno. It's great so far. Thank you everyone for your hard work and contributions.

A main development pain point I experience is importing new packages. I have to visit the package documentation, and get the url. Even for packages I have already used, I have to go to the documentation every time to copy the really long url.

Now most of us deno users would be coming from npm, so it'd be more productive to be able to use common packages without having to visit documentations all the time to copy the url.

With node, I could just npm i express, then require('express'), because express is easy to remember.

My suggestion is to have similar functionality with deno. We could have an alias for urls. For example, import * as log from 'log' resolves to import * as log from 'https://deno.land/std/log/mod.ts'. Deno just resolves the alias behind the scenes.

I hope the suggestion makes sense. Looking forward to what you think, or any drawbacks and feedback. Thanks !

[nayeemrmn]

Duplicate of #3311. Use import maps for this: https://deno.land/manual/linking_to_external_code/import_maps.

[bahdcoder]

Thanks for your reply. With this issue, as I mentioned, the problem I faced (which most developers will likely face) is productivity.

Let's take an example. I need to install log package for my development. I could just import * as Log from 'log' since I have used this package in the past, but no. I have to go to a browser, google deno log then copy the url of this package and include in the project.

The problem is using memorable names to speed up package installation. That way developers can rapidly install, recommend, or generally talk about packages without the need for long urls.

This could be fore

[nayeemrmn]

So rather than the importing aspect you're talking about name resolution on the publishing and installing side -- an npm equivalent? By definition you're asking for a package manager which as clearly stated here is out of scope for Deno. You can use a higher order tool for this if you want, Just like npm pretty much is to Node.

---

Duplicate of #47! I'm sorry to say it like this but what you're discussing is literally the first question anyone has when they learn about Deno's module system. A suggestion as simple as this has, as you'd expect, been duplicated in countless issues already. The project didn't just come into existence yesterday.

An acceptable new issue should include a concrete and original suggestion as to how you could achieve a comparable developer experience without simply introducing a package manager.