[wwwigham]

Deno has _very_ custom module resolution rules. The first thing you notice is the required `.ts` extensions and browser-esque URLs. Oh, and also the import maps proposal (which is its own can of worms). Then you dig a little deeper and learn that deno also supposedly supports all `node` resolution rules sometimes via compat flags. Then you learn that it pulls types from magic `/// <reference types` comments, which sounds like what TS normally does, until you realize deno uses it to _override_ the types for JS files, and not pull in new files, which isn't something TS does at all. Oh, and `@deno-types` comments for overriding individual imports, besides.

One of the first lines in the deno docs is:

> Deno has no "magical" module resolution.

Which, as an implementor of module system rules, seems incredibly far from the truth of the matter (where deno has the most complex resolution rules of any runtime currently in use). I think maybe there were simple goals at the start, but that came crashing against reality and xkcd 927 executed in full force.

[kitsonk]

I would argue it isn't very custom. Using fully qualified URLs predates Node.js and CommonJS. It was also one of the big debates when we all were doing AMD. Node.js has realised that _mistake_ of eliding extensions and is headed that direction as well.

We have been adding a Node.js compatibility mode, but I am not sure that qualifies as "_very_ custom module resolution".

Both the triple-slash reference and @deno-types were solutions to problems to not have opaque type resolution with TypeScript. They do not impact the runtime resolution, only the type check resolution. Instead of opaquely searching for these by reading the `package.json` and probing the file system like `tsc`, Deno is explicit.

I would be glad to work with you to explore how we can figure out how to resolve your implementor concerns. The door has been open for a long time, and I have mentioned it in passing to Daniel a couple times. Let me know if you would like to talk.

[nsonha]

this is web dev mindset, in all other languages the module name is just a name, it's not supposed to tell you how to retrieve the module, that's the job of the module system. Otherwise it's the service locator anti pattern. I always find it redundant that syntacically, the module name in javascript has to be a string (as in quoted) for whatever reason. In python and php it's just tokens and namespace separator.