The new npm import is a much required step in the right direction. The next step would be to allow namespacing of other / default repositories.

```

import namespace npm

import { chalk } from "chalk"

import { assert } from "test"

…

import namespace local

import { chalk } from "mychalk.ts"

import { assert } from "test"

// who needs extensions anyways?

```

a) They intentionally want to segregate NPM imports, because this is a stopgap, not the way forward they're trying to lay out for the ecosystem. The future Deno is aiming for is one where you don't have repositories (as we've known them), only web domains.

b) The above introduces non-standard JS syntax and semantics, which also goes against Deno's philosophy

b) that's a valid argument. so Deno.namespace("npm") would be the way

a) that's fine. In fact namespacing helps with segregation, because once there is some "npm for deno" one would just set the appropriate Deno.namespace("default") without having to touch a million import "npm:package_xyz".

Explicitly repeating full paths such as

import { createRequire } from "https://deno.land/std/node/module.ts";

over and over again is just an ugly antipattern.

Deno already supports "import maps" for this. [1] There's one example in the linked article even.

You create an import map JSON file that tells Deno that maps human useful "short names" and "short paths" to full URLs (including `npm:package@version` URLs).

[1] https://deno.land/[email protected]/basics/modules/import_maps

Interesting!