Support publishing to registry with an importmap

[dsherret]

It might be useful for people to publish to the registry with the import map unfurled.

For example, say the module has an import map like so:

{
   "imports": {
      "fmt/": "https://deno.land/std@0.108.0/fmt/"
   }
}

And a TypeScript file like so:

import { red } from "fmt/colors.ts";

console.log(red("hello world"));

The user would be able to somehow specify "here's the import map to use for my module" to the registry (edit: nowadays, probably automatically resolved from deno.json/jsonc or perhaps this could be a GH action build step) and it would be published to the registry as:

import { red } from "https://deno.land/std@0.108.0/fmt/colors.ts";

console.log(red("hello world"));

[albnnc]

Does this mean that every **/*.{ts,tsx,js,tsx} file located in repo is going to be transformed?

Corner case

Suppose me creating something like framework that is going to have a project init script. This script is going to copy some *.ts files which actually use entries from import map, that is also going to be copied during user project creation.

This means that in that particular case only a subset of **/*.{ts,tsx,js,jsx} files should be transformed. How is this going to be handled?

[aapoalas]

Would it rather make sense to provide an unfurling script?

[dsherret]

Would it rather make sense to provide an unfurling script?

@aapoalas Yes, I think ideally it would be a separate script that runs as part of a GitHub action step. This allows people to give the registry the exact code they want it to serve.

Suppose me creating something like framework that is going to have a project init script. This script is going to copy some *.ts files which actually use entries from import map, that is also going to be copied during user project creation.

This means that in that particular case only a subset of **/*.{ts,tsx,js,jsx} files should be transformed. How is this going to be handled?

@albnnc normally for project init scripts people don't copy over straight files, but instead things are generated because there will be some conditionals. So generally, people would do a straight copy of a file to another file. That said, there would be ways around this such as using the github action with this setting turned off, saving the template file with another extension, or using different import map entries in the module compared to the user's import map.

[harrysolovay]

I'm wondering if the solution here may also apply to the following:

Let's say that a given lib contains an example/a.ts.

It would be nice for potential users to be able to interact with this example without needing to clone the project. Aka.

deno run -A https://deno.land/x/<the-project>/examples/a.ts

If, however, examples/a.ts uses an import-mapped specifier, then the potential user must also specify the import map.

deno run -A https://deno.land/x/<the-project>/examples/a.ts \
  --import-map=https://deno.land/x/<the-project>/import_map.json

This is unfortunate. Any ideas on how to enable the first, simpler example run command?

[idranme]

Good idea.

[dsherret]

No longer relevant with the release of https://jsr.io

This now happens automatically on deno publish