Just so I understand this correctly from your comment here, because Browserify ignores exports, the paths on the left-hand side of exports (aside from ".") need to be written so that they resolve to real files in the filesystem. We do this so that if the extension uses a library that contains a subpath import e.g., @metamask/key-tree/dist/cjs/some/path, will continue to work.

However, this seems to imply two things: 1) the responsibility for resolving an import path shifts from the consumer to the library itself, and 2) we cannot create fully ESM-compatible libraries.

Say we publish a library that contains a subpath import of another library. Ideally we could use a shortcut for that import (e.g. @metamask/key-tree/some/path) and it would resolve to either the CJS or ESM version depending on what the consumer is using (a bundler or straight Node). But we can't do that, so we have to be explicit and use the CJS version (@metamask/key-tree/dist/cjs/some/path).

But if we do that, wouldn't this mean that in the compiled version of our library, both the CJS and ESM builds will contain this import? So even if in our ESM build, we'd potentially have a mixture of ESM and CJS?

Could you give an example of "a subpath import of another library"? I'm not sure what that means, or why we'd want to support it.

But if we do that, wouldn't this mean that in the compiled version of our library, both the CJS and ESM builds will contain this import? So even if in our ESM build, we'd potentially have a mixture of ESM and CJS?

Yeah, that's the downside of doing this. I thought about doing something like this:

{
  "./dist/cjs/*": {
     "import": "./dist/esm/*.js",
     "require": "./dist/cjs/*.js"
  }
}

So even if you import ./dist/cjs/foo, and your bundler supports exports, it will resolve to ./dist/esm/foo. But this feels very hacky.

I wonder if there's a way to support exports in Browserify through a plugin, but I couldn't find anything about this. That would solve all problems I think.

Could you give an example of "a subpath import of another library"? I'm not sure what that means, or why we'd want to support it.

For example:

• utils imports abi-utils/dist/cjs/foo
• snaps-utils imports utils.
• snaps-utils is now indirectly using abi-utils/dist/cjs/foo, even though the bundler may support ESM.

Thanks, my brain somehow read "subpath import" as "subpath export". That makes more sense.

This is useful for resolving the root of the package. I'm not sure if it should be added to the module template, but it doesn't hurt I suppose?

We use this in the Snaps repo several times, which doesn't work without this line:

path.dirname(require.resolve('package/package.json'));

Interesting. I guess it doesn't hurt 🤷

Apparently Node.js doesn't allow using .js for both the CJS and ESM version in the same project (??), but you can work around it by adding a package.json to the ESM folder.