Deno: Allow wildcards in import maps

[jpike88]

This is my import map, taking straight from tsconfig/paths

{
    "imports": {
        "@shared/*": [
            "../../shared/*"
        ],
        "@server/*": [
            "./components/*"
        ],
        "@brand/config.json": [
            "../config.json"
        ]
    }
}

I get this error

error: Uncaught ImportMapError: Unmapped bare specifier "@server/core"

Wildcards are important for pulling in shared codebases, keeping paths standardised across multiple projects. And also maintains proper compatibility with tsconfig paths statements.

This allows me to keep my import statements nice and compact, for readability's sake.

[kevinkassimo]

ref: https://github.com/WICG/import-maps/issues/7

[jpike88]

import-maps looks like it's moving real slow.... hopefully Deno doesn't wait for it to reach a conclusion

[bartlomieju]

@jpike88 @kevinkassimo I followed your discussion on Gitter.

It seems https://github.com/WICG/import-maps/issues/7 has stalled and there is no consensus yet. I would very much like to avoid implementing parts that are not yet specced - also there are other parts on spec that we should have before that (ie. merging import maps).

That said I believe you could make it work with little change to your import map:

{
    "imports": {
        "@shared/": [
            "../../shared/"
        ],
        "@server/": [
            "./components/"
        ],
        "@brand/config.json": [
            "../config.json"
        ]
    }
}

Also we might discuss some further use of paths in tsconfig.json, CC @kitsonk

[jpike88]

Great... but now I've run into https://github.com/denoland/deno/issues/2506

[kitsonk]

My opinion is not to use something that isn't on a standard track. The behaviour of paths in the tsconfig.json was designed to mimic other loaders (like AMD, SystemJS) and other bundlers (like webpack). We _can't_ use it in the compiler (as it does no module resolution) and so we ignore it and warn that we ignore it. I say we keep it that way. We wouldn't want to take away import-maps, because it is a shipping standard (Chrome 74) and mediating between that and paths would be horrible.

[jpike88]

But that will create a rather annoying barrier for entry for existing codebase migrations, and cause confusion amongst devs who are experienced in TS conventions, myself included. It's not just a minor tweak in a config file, it's a fundamental change to how our projects are structured, beyond current TS conventions and rules. I haven't even heard of import-maps till now, and I'll may never have to if I don't use deno, as it would be entirely up to the whims of TS.

Like I said in my other comment, you could wait it out until the TS team decides to make the requisite tweaks to match these standards. But that might delay exposure and adoption of deno for quite some time. If that's intentional, then I guess I have no argument.

[kitsonk]

I haven't even heard of import-maps till now, and I'll may never have to if I don't use deno, as it would be entirely up to the whims of TS.

You will hear of import-maps, it solves a big problem that people have been avoiding. Chrome shipped the first built-in module, and it uses import maps is specifically designed to allow the loading of polyfills where the modules are not built in. Built in modules are a thing, import maps are a thing. Just because you weren't aware of them doesn't mean they weren't a thing.

One could argue we aren't building something for today, we are building something for tomorrow. Deno is very unstable. It will likely still have major breaking API changes, but we know some principles, which are to build on open web standards. We waited to even consider solving the problem of module remapping until import maps shipped in at least one browser. Also, Deno isn't designed to be TypeScript only. It can and should run JavaScript just perfectly fine and tying a feature related to resolving modules to a TypeScript configuration file doesn't make a whole load of sense in my opinion.

[kevinkassimo]

One could argue we aren't building something for today, we are building something for tomorrow.

I agree on this part.

Deno is born to experiment with new standards and more web APIs. It is destined to be unstable at this moment, like the early days of Node. But it is different from Node nowadays, what Node might dare not to do because of backward compatibility and community backlash for even simply a small behavioral change, we go and experiment for better. Otherwise why are we even trying to build it?

TypeScript is built with the knowledge of existing technologies. Deno is too new to the TypeScript people, just like Node was too new to v8 people years ago. Node only receives decent attention from v8 after it grows along its own path, and I would imagine the same for Deno if it were to be successful, under the precondition that I (personally) would rather it fail instead of surviving under the unreasonable fear from the Old Ones (tipping hat to Lovecraft).

[kitsonk]

Deno is too new to the TypeScript people

Well, they know quite a lot about us... But diverting core team engineering effort is a different story. We have snapshotting capability in Deno, something that TypeScript was looking at to increase the performance of tsc and I did a POC with it a while ago, something I should dust off again (now that we split core and TypeScript has done some performance refactorings). The original POC didn't actually make a significant difference to the performance of tsc because tsc doesn't allocate a lot of objects until it starts actually starts building a project, so to get real advantages, tsc would need to be pre warmed.