Import relative project with it's own import map?

[sullen goblet]

I'm developing a Deno framework, let's call it Argos. Like Oak/Express/Koa/etc., it is used to build applications on top of. I have another project (let's call it Deimos) that uses Argos.

Argos uses NPM specifiers for imports declared in an import map, and an alias for the lib folder, similar to this:

{
  "imports": {
    "~/": "./lib/",
    "envalid": "npm:envalid"
  }
}

My file heirarchy looks like this:

- projects
  - argos
    - mod.ts
    - import_map.json
  - deimos
    - mod.ts
    - import_map.json

I'm having trouble importing Argos inside of Deimos. If I try the following inside Deimos:

import * as argos from "../argos/mod.ts";

... that "works" but none of my imports are typed; as in, Deno can find the file at that location, but it cannot resolve any of the imports in Argos' import_map.json (eg., all of the "~/" import statements inside Argos) because they aren't declared in Deimos' import map. Anything I import has the type "any".

If this were a Node project, I might use a library like Yalc to do a "local publish" of Argos, but it's unclear to me what the Deno equivalent might be. I'm rapidly developing Argos and find it very useful to design the public API by frequently integrating it into Deimos.

Is there a pattern in Deno to support this type of development that I'm missing?

[ripe rampart]

Huh, I'm surprised that the docs for import maps (https://deno.land/manual@v1.29.1/basics/modules/import_maps) don't say this but it's important to know -- import maps are only read and respected for the top-level deno application. So if you're planning to publish some code as a library, you should avoid using import maps for that project.

Instead, the pattern is to publish a top-level mod.ts that exports all of your public functions/classes/types/etc. The library should use the deps.ts pattern as described here: https://deno.land/manual@v1.29.1/examples/manage_dependencies

aha, if you click into the "import maps" link in the first link I shared above, you do eventually get to:

Import maps are an application-level thing, somewhat like service workers. (More formally, they would be per-module map, and thus per-realm.) They are not meant to be composed, but instead produced by a human or tool with a holistic view of your web application. For example, it would not make sense for a library to include an import map; libraries can simply reference modules by specifier, and let the application decide what URLs those specifiers map to.
https://github.com/WICG/import-maps#scope

[ripe rampart]

I submitted a PR to update the Deno docs on import maps.

https://github.com/denoland/manual/pull/499