deno publish --resolve-import-map-specifiers flag

[andykais]

per the deno docs import maps are currently only usable by "applications" in deno. This means that any library development must stick to a deps.ts pattern, and not use import maps for any other niceties. For me personally, that main nicety is the ability to use project oriented root paths, which makes refactors a lot easier to manage.

I feel that it should still be possible for library maintainers to use import maps since they offer a lot of value to development. A possible solution to this problem is a transpilation between deno publish and jsr that resolves import maps back into bare specifiers. Something like the following:

deno publish --resolve-import-map-specifiers=import-map.json

where the argument is optional, defaulting to deno.json imports if they exist. Then an import map specifier like so:

// deno.jsonc
{
  "imports": {
    "@std/fs": "jsr:@std/[email protected]",
    "~/": "./"
  }
}

and a source file like this:

import * as fs from '@std/fs'
import db from '~/db/mod.ts'

might resolve to something like this:

import * as fs from 'jsr:@std/[email protected]'
import db from '../db/mod.ts'

I came to this conclusion because I cant really see a world where changing the import map spec to support nest is something that could be solved in any reasonable timeline since its tied into web specifications. The only possible downside to this approach I see is that code that is retrieved from jsr isnt exactly the same as the code that it references on a github commit, which possible would break the provenance that jsr offers as one of its core advantages over npm

[andykais]

ok wow thats some funny timing. The deno 1.45 release introduced "workspaces". It seems like this could possibly solve my issue if I am able to import from a package within itself (and then have jsr publish resolve those back into usable imports. I was able to get a basic version of this working, the general jist is this:

// ./deno.jsonc
{
  "workspaces": {
    "members": ["./packages/core", "./packages/cli"]
  }
}

// ./packages/core/deno.jsonc
{
  "name": "@forager/core",
  "exports": {
    ".": "./src/mod.ts",
    "./errors.ts": "./src/errors.ts"
  }
}

// ./packages/core/lib/util.ts
export * as errors from '@forager/core/errors.ts'

I havent yet proven if this will do the right 'magic' when this publishes to jsr to unwind these kinds of exports. Two pain points here though:

1. exports currently requires explicit exports only. As far as I can tell, there are no directory exports or glob exports, so it means every single file needs to be defined in the exports field just to make for more convenient "root" imports within a project
2. exports should really just be used for defining usable package exports. This approach bloats the jsr package manifest.

[andykais]

An inverse approach here is defining imports top level. E.g.

// ./deno.jsonc
{
  "imports": {
    "@forager/core": "./packages/core/src/mod.ts",
    "@forager/core/": "./packages/core/src/",
  },
  "workspaces": {
    "members": ["./packages/core", "./packages/cli"]
  }
}

// ./packages/core/deno.jsonc
{
  "name": "@forager/core",
  "exports": "./src/mod.ts"
}

and usage remains the same:

// ./packages/core/lib/util.ts
export * as errors from '@forager/core/errors.ts'

This feels more like what I want, but I still dont know if jsr will resolve these effectively. It is worth mentioning that deno_std uses imports in the top level workspace deno.json, but those imports reference jsr specifiers, not local files https://github.com/denoland/deno_std/blob/main/deno.json