Deno: Rename --importmap to --import-map

[nayeemrmn]

I suppose --importmap came from <script type="importmap"> in the proposal. However in _every_ other usage it is referred to as two words: "import map", "import-map" or "importMap". It would be much less of an eyesore (currently --importmap is the only flag formatted this way) if we followed our own convention for this and hyphenated it to --import-map.

[kevinkassimo]

This probably needs more feedback from opinion of others. On the other hand just make both the correct flag names might also be fine and the added cost of maintenance should be acceptable.

[bartlomieju]

We should remove import map support altogether...

[caspervonb]

We should remove import map support altogether...

Just note that we can't have any sort of meaningful esm-integration without import maps. The proposal implicitly relies on there being a way to resolve system imports.

[buttercubz]

We should remove import map support altogether...

why remove the support? I think it is the best way to handle multiple dependencies, also using a single deps.ts file feels like a patch rather than a solution.

[crowlKats]

@buttercubz no other browser supports it and dependencies cant use it

[buttercubz]

@crowlKats Yes, I know that it is far from being a standard, but also using a large-scale url is very complicated.

[bartlomieju]

We should remove import map support altogether...

Just note that we can't have any sort of meaningful esm-integration without import maps. The proposal implicitly relies on there being a way to resolve system imports.

@caspervonb I'm not following, could you elaborate?

[caspervonb]

We should remove import map support altogether...

Just note that we can't have any sort of meaningful esm-integration without import maps. The proposal implicitly relies on there being a way to resolve system imports.

@caspervonb I'm not following, could you elaborate?

Toolchains (and libraries) make liberal use of bare imports as there is no way of knowing what the import will resolve to in a portable runtime agnostic module; like env, wasi_unstable, wasi_snapshot_preview1, et cetera.

The esm-integration proposal is aware of this, discussions on it have resolved it as out of scope for esm-integration and left it up to another proposal to deal with module resolution. Up til recently we believed this to be the import map proposal but given that it's dead in the water right now without any vendor signals I'm not sure what we'll end up with.

But as the only "vendor" implementing it, I do think we're in a position to shape it rather just up straight dropping it. Do we have any feedback to bring back to the import-maps proposal?

[nayeemrmn]

Either way we'll never stabilise it until it is an adopted standard. So I guess removing it on the grounds that, there's currently no sign it will ever be that, is valid. But is that really the case, or will removing it just lead to unnecessary churn? See https://github.com/denoland/deno/issues/4958#issuecomment-620637989.

[brandonkal]

Another vote against removing importmap support. There is a big difference between using an import_map.json and a deps.ts file. Any script that depends on a deps.ts file will have to download and compile everything. Meanwhile with an importmap, I can refer to a dependency with a shorter specifier with no runtime performance hit.

Compare:

// deps.ts
export * as kubernetes from 'https://cdn.jsdelivr.net/gh/brandonkal/deno-lib@master/kubernetes.ts'
export * as rt from 'https://cdn.jsdelivr.net/gh/brandonkal/deno-lib@master/runtypes.ts'

```ts
// file A
import { rt } from '../../deps.ts'

Versus if an import map exists
```ts
// file A
import * as rt from 'lib/runtypes.ts'

The latter will compile much faster and importantly, unneeded files won't be downloaded and type-checked.

And frankly at that point you are back to where node is. You are not downloading a whole tarball and only using part of it, but you are doing essentially the same thing except this time you could be downloading and compiling hundreds of files.

Import maps also make it easy to switch out implementations. Perhaps an example will help. Here's an example where I benefit from the import map: https://github.com/brandonkal/empty-testbed/blob/master/brigade.ts
It is Brigade, but I've created a Deno worker which is very nice for dependencies and TypeScript.
With a simple import map, the user can download types to write the pipeline (as I've done there, not public yet). The actual implementation is stubbed. Then in the CI worker, an import map replaces the library with the actual implementation. Importantly, the CI pipeline file is self-contained (it doesn't depend on another file in the repository which would be unavailable before the job began).

So deps.ts doesn't replace the import map despite looking similar. There are cases where removing import map support would mean a lot of inefficiency and downsides.

I am for the rename to --import-map.

[caspervonb]

Either way we'll never stabilise it until it is an adopted standard. So I guess removing it on the grounds that, there's currently no sign it will ever be that, is valid. But is that really the case, or will removing it just lead to unnecessary churn? See #4958 (comment).

I think it's still a bit pre-mature to kill it right now.

While it seems like this will inevitably die as all we really have to go on right now is a mention that "Apple may be interested" (https://github.com/WICG/import-maps/issues/212#issuecomment-663562473).

[nayeemrmn]

The latter will compile much faster and importantly, unneeded files won't be downloaded and type-checked.

@brandonkal I don't get it. How common is it to have potentially unused immediate dependencies in a non-library application? That's the only place where import maps actually work.

[brandonkal]

Very common. There is no tree shaking in deno.
If there were you'd still waste cycles downloading everything to build a graph.

To be clear, import maps work everywhere you consume code.

[nayeemrmn]

@brandonkal I meant unused immediate dependencies. Import maps won't do anything for unused transitive dependencies, right?

To be clear, import maps work everywhere you consume code.

And libraries don't consume code, they get consumed by the runtime of of the library's user at the application level.

[brandonkal]

Yes that's why you author your library to not have unused deps to avoid the unused transitive issue.

[nayeemrmn]

Yes that's why you author your library to not have unused deps to avoid the unused transitive issue.

@brandonkal I'm not sure what we're talking about now. I explained that import maps can only be used for immediate dependencies at the application level, and there is no reason to have any unused immediate dependencies at the application level.

Is there a realistic reproduction or example application you can link to with an import map that we can replace with deps.ts and compare the cache size? Since this is informing a Deno feature decision.

[nayeemrmn]

@bartlomieju Recent Chromium intent to ship: https://github.com/WICG/import-maps/issues/217#issuecomment-632314791 / https://github.com/WICG/import-maps/issues/212#issuecomment-663564421 (only delayed due to COVID). There's plenty of recent discussion and pushes for it, particularly from Node. I get the impression that the inactivity in the proposal is just stability. I'm also against removal at this time.

In terms of use cases, I completely disagree with those attempting to use it for regular dependency management. But it has some nice sandboxing capabilities: https://github.com/denoland/deno/issues/6294#issuecomment-663256029 and is a good tool for other edge cases.

[teleclimber]

Yes, I am depending on importmap aka import-map to close some holes that Deno leaves open as described by @nayeemrmn in #6294. Please don't remove this unless you provide an alternate way of achieving better sandboxing.

[lucacasonato]

Yes, I am depending on importmap aka import-map to close some holes that Deno leaves open as described by @nayeemrmn in #6294. Please don't remove this unless you provide an alternate way of achieving better sandboxing.

The more proper solution (also described in #6294) is to serve your files from a local webserver. This will prevent file:// imports.

[kitsonk]

We shouldn't remove import map support. I think it got stalled for a lot of other reasons than stability. Mostly because there was a bit of wider push back from non-Chromium world and how fast it and other things (like built in modules) were going. Clearly it solves a problem that needs to be solved.

As far as renaming... 🤷 but I do like --import-map better.

[JayHelton]

Whats the final consensus for this suggestion? I also prefer --import-map as the flag name. For the sake of quality, I think renaming it would be a good idea.

[timreichen]

Also agree to keep the support. Killing it would send a false signal surely.
+1 for renaming to --import-map.

[noteScript]

At present, importmap is only applicable to the run command. When can it be supported on the install command?

[caspervonb]

In addition to the type for the script tag, the proposed mime type is application/importmap+json 🤔