Fixing DEP0148: Folder mappings in "exports" (trailing "/") leads to Error: Cannot find module

[11331133]

Version

v16.20.2

Platform

Linux user 5.15.0-84-generic #93~20.04.1-Ubuntu SMP Wed Sep 6 16:15:40 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

Steps to reproduce:

1. Clone repo https://github.com/11331133/exports-subpath-patterns-bug:

git clone [email protected]:11331133/exports-subpath-patterns-bug.git
cd exports-subpath-patterns-bug

2. Make sure everything works:

node entry.js

// console.log({ a }) outputs { a : 1 } and deprecation warning to the console

3. Change exports in node_modules/pkg-subpath-exports-issue/package.json:

-       "./": "./"
+       "./*": "./*"

4. Run:

node entry.js

5. Error occurs

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior? Why is that the expected behavior?

console.log({ a }) outputs { a : 1 } to the console

What do you see instead?

node:internal/modules/cjs/loader:562
throw e;
^

Error: Cannot find module '/exports-subpath-patterns-bug/node_modules/pkg-subpath-exports-issue/folder1'
at createEsmNotFoundErr (node:internal/modules/cjs/loader:1055:15)
at finalizeEsmResolution (node:internal/modules/cjs/loader:1048:15)
at resolveExports (node:internal/modules/cjs/loader:556:14)
at Function.Module._findPath (node:internal/modules/cjs/loader:596:31)
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1014:27)
at Function.Module._load (node:internal/modules/cjs/loader:873:27)
at Module.require (node:internal/modules/cjs/loader:1100:19)
at require (node:internal/modules/cjs/helpers:119:18)
at Object.<anonymous> (/exports-subpath-patterns-bug/entry.js:1:15)
    at Module._compile (node:internal/modules/cjs/loader:1198:14) {
        code: 'MODULE_NOT_FOUND',
        path: '/exports-subpath-patterns-bug/node_modules/pkg-subpath-exports-issue/package.json'
    }

Additional information

I'm trying to address DEP0148: Folder mappings in "exports" (trailing "/") warning by using subpath patterns. Unfortunately, changing exports leads to module not found error.

I've also tried to change the exports config this way:

    "./": "./",
    "./package.json": "./package.json",
    ".": "./index.js",
    "./*/": "./*/index.js",
    "./*": "./*.js"

Unfortunately, this configuration still leads to an error

[aduh95]

It would be helpful if you were able to provide a simpler repro, one that doesn't require to download code from the internet, and maybe with fewer files also.
Would the following be a good illustration for what you are doing?

/// ./dist/folder1/index.mjs
export const a = 1;

/// ./entry.mjs
import { a } from 'pkg/folder1';
console.log({ a });

{
  "name": "pkg",
  "exports": {
        "./package.json": "./package.json",
        ".": "./dist/index.mjs",
        "./*/": "./dist/*/index.mjs",
        "./*": "./dist/*.mjs"
  }
}

[11331133]

Hi @aduh95,
Thanks for the feedback. I updated the repository. There are 3 .js files now and 2 folders, zero dependencies. I also updated the issue decription.

[aduh95]

Thanks! Unfortunately, I think everything is working as expected. The goal is that resolution algorithm should not need to make any FS call to get the complete URL, and the file could even be created on the fly between the resolution and the load call. That's why you need to either define an explicit ./folder1/ entry in your "exports" map, or add a folder1.js file that exports everything from ./folder1/index.js.

/cc @nodejs/loaders can someone confirm if my understanding is correct?

[11331133]

@aduh95 thanks for response. So, is there really no other way than explicitly specifying all folder paths in the package.json's exports? We have a large number of folders (and subfolders), and duplicating and maintaining the folder structure in exports is time consuming for us. Creating a script for this also doesn't sounds right.

/cc @nodejs/loaders

[JakobJingleheimer]

I believe the CJS-like resolution you're trying to do here is explicitly not supported for, among other reasons, what aduh95 said.

[11331133]

It makes sense, thank you for help @aduh95 @JakobJingleheimer