Deno fails when a package in a monorepo uses a ./* export

[michael-aldridge-pozlo]

Deno version

$ deno --version
deno 2.0.4 (stable, release, x86_64-unknown-linux-gnu)
v8 12.9.202.13-rusty
typescript 5.6.2

To demonstrate the issue I created the following mono-repo

$ tree
.
├── a
│   ├── deno.json
│   └── src
│       └── index.ts
├── deno.json
└── index.ts

The root deno.json just specifies the a package

$ cat deno.json 
{
    "workspace": ["./a"]
}

The a package has a single export

$ cat a/src/index.ts 
export const foo = 42;

and a minimal deno.json

$ cat a/deno.json 
{
    "name": "@github-issue-example/a",
    "exports": {
        ".": "./src/index.ts",
        "./*": "./src/*"
    }
}

finally, the root module index.ts files contains a single export

$ cat index.ts 
import { foo } from "@github-issue-example/a/index.ts";

This sort of set up worked fine with node but deno is not happy about this import

$ deno run index.ts 
error: Relative import path "@github-issue-example/a/index.ts" not prefixed with / or ./ or ../ and not in import map from "file:///home/michael/github-issue-demos/deno-monorepo/index.ts"
    at file:///home/michael/github-issue-demos/deno-monorepo/index.ts:1:21

If I change the export map in a/deno.json to explicitly list index everything works fine, i.e.

$ cat a/deno.json 
{
    "name": "@github-issue-example/a",
    "exports": {
        ".": "./src/index.ts",
        "./index.ts": "./src/index.ts"
    }
}

This would seem to be a bug to me but it might be a feature request, I can't quite tell from the documentation. Any advise or help greatly appreciated. Thanks.

---

This issues looks similar to #20513 but I thought it different enough to warrant a separate issue.

[bartlomieju]

I believe this is working as intended. deno.json exports expects all entry points to be listed out verbatim and doesn't support "globs" like ./*.

@dsherret can you please confirm it?

[michael-aldridge-pozlo]

Ah okay. Thanks for the clarification.

[dsherret]

Yeah, it needs to list out the exports. There's some cases where we go from the deno.json or manifest to all the exports (ex. linting no-slow-types and deno install). It's a little tricky how that could work if we allowed wildcards (ex. we'd probably have to not consider files that are excluded from publish when doing this locally and remotely we'd have to look at the manifest items to figure out the modules).

I opened denoland/deno_config#134 for now.