Closed Mrtenz closed 1 year ago
Perhaps we could omit the dist/*
exports, and commit ourselves to not relying on file imports anymore? We can be more diligent about updating the package exports for our libraries. That's something we've been trying to do anyway, this can serve as a good excuse.
Perhaps we could omit the
dist/*
exports, and commit ourselves to not relying on file imports anymore? We can be more diligent about updating the package exports for our libraries. That's something we've been trying to do anyway, this can serve as a good excuse.
I'm not sure how much work would be involved in this, but if it's not too much, that seems like a good option too. A regex search in the Snaps repo (import .* from '@metamask/.*/.*'
) shows there's a couple of cases where we do this, which can be easily addressed.
Perhaps we could omit the
dist/*
exports, and commit ourselves to not relying on file imports anymore? We can be more diligent about updating the package exports for our libraries. That's something we've been trying to do anyway, this can serve as a good excuse.
I like this. Maybe it shouldn't be a blocker for this PR? But I do think it's a good idea.
Following discussion in #203, I removed the
exports
field from thepackage.json
because it seemed unnecessary. Unfortunately, not having it breaks when importing a package when Node.js is running in ESM mode, because Node.js doesn't look at themodule
field at all. This causes issues like in MetaMask/key-tree#144.This adds a two exports fields:
.
: The main export, which is used when importing a package from the root. This means that we cannot reliably import from subpaths anymore../package.json
: To allow resolving thepackage.json
path (and importing it, if desired), we also export this.Since Browserify does not support the exports field, we can't use
./*
exports (i.e.,package/foo
resolves topackage/dist/esm/foo
orpackage/dist/cjs/foo
depending on the environment), as it would break in the extension.