No support for subpath patterns?

[dschnare]

Esmock seems to have trouble resolving modules from packages with "exports" that use subpath patterns.

Some package (my-pack)

{
  "exports": {
    "./*": {
     "default": "./src/*/index.js",
     "types": "./types/*/index.d.ts"
    }
  }
}

Then in another package for example.

import { Something } from 'my-pack/stuff' // this line fails due to module ID not being found

[dschnare]

Reference: https://nodejs.org/docs/latest-v18.x/api/packages.html#subpath-patterns

[dschnare]

Interestingly, this error only occurs for me for some subpaths and not others from a package. To workaround I had to use the pattern to catch most subpaths then have an explicit export for subpaths that cause the error.

{
  "exports": {
    "./*": {
     "default": "./src/*/index.js",
     "types": "./types/*/index.d.ts"
    },
    "./my-path": {
      "default": "./src/my-path/index.js",
      "types": "./src/my-path/index.d.ts"
    }
  }
}

[iambumblehead]

@dschnare subpaths are supported and if one is not resolved correctly that's a bug. esmock uses resolvewithplus to resolve module ids, so that's where the solution should happen.

Node's dsl esm pattern language is tricky to parse. For resolvewithplus, official node examples were copied to unit-tests used by resolvewithplus and when missing cases have been discovered they've been resolved in new versions of resolvewithplus

[iambumblehead]

@dschnare I have not seen wildcard export namespace names before, eg {"exports":{"./namepace*": { ... }}} that usage does not appear to be documented at the link you shared.

[dschnare]

Wildcard no, but using the asterisk to match a folder works and documented. It’s a weird thing to have most of the folders match and only a few give issues but that’s what is happening for sure. Anyway, I do have a work around but less than ideal. Thanks for responding so quickly. When I have time I will investigate the package you mentioned and see if I can repro in a simple example.

…

On Mon, Jan 22, 2024 at 1:07 AM, iambumblehead ***@***.***(mailto:On Mon, Jan 22, 2024 at 1:07 AM, iambumblehead <<a href=)> wrote: ***@***.***(https://github.com/dschnare) I have not seen wildcard export namespace names before, eg {"exports":{"./namepace*": { ... }}} that usage does not appear to be documented at the link you shared. — Reply to this email directly, [view it on GitHub](#289 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAG2DNOIER2SZVXZGD2BZKDYPX6YTAVCNFSM6AAAAABCEFCSH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBTGMZDIMRTHA). You are receiving this because you were mentioned.Message ID: ***@***.***>

[iambumblehead]

@dschnare thanks for reporting. Its always good to learn about these cases I didn't know about.

[iambumblehead]

@dschnare is this what you think the exports, directory and file layout should look like for unit-testing this?

{
  "name": "asterisk-dir-name",
  "type": "module",
  "exports": {
    "./*": {
      "default": "./src/*/index.js",
      "types": "./types/*/index.d.ts"
    }
  }
}

.
├── package.json
├── src
│   └── mystuff
│       └── index.js
└── types
    └── mystuff
        └── index.d.ts

[iambumblehead]

@dschnare I wonder specifically how the named-property asterisk and then its nested, matched value must correspond to each other and the specifier used to import such a module.

For example, should the outer "./*" return any directory or only a directory that corresponds with the imported moduleId?

Maybe we should first implement any basic solution and then refine that later as any edge-cases are reported to fail.

[iambumblehead]

@dschnare iambumblehead/resolvewithplus#65

[dschnare]

That test scenario is perfect. That's what we have currently in our project. Some folders work, while others didn't so I had to specifically add an export for that folder.

[dschnare]

@iambumblehead It looks like from the documentation that the subpath pattern ./* would match any path like "mymodule/something", "mymodule/something/cool", etc. And technically * could be included multiple times in the export pattern. This I didn't know, but interesting.

All instances of * on the right hand side will then be replaced with this value, including if it contains any / separators.

[iambumblehead]

@dschnare the PR was just updated so that the tests will pass in windows. Feel free to recommend any changes

[dschnare]

@iambumblehead I understood that incorrectly. The * can appear multiple times on the right side. On the left side it appears it should only occur once.

[iambumblehead]

if the overall approach is okay (as it seems to be) its good for me if the PR is accepted. Later on, when needed, the place that expands the asterisks on the right side could be improved for supporting more situations.