Support "exports" ("require" "import") property in package.json

[btakita]

It looks like bundt supports "main" & "module". To better support ESM, I found that vendorizing this repo & using "exports" fixed an import issue, instead of "main" & "module".

This occurred with the mri repo, where I vendrized it & used:

"exports": {
  ".": {
    "require": "./lib/index.js",
    "import": "./lib/index.mjs"
  }
}

[lukeed]

Hey what does vendorizing mean?

In reality, even with exports defined, main and module should still be used and defined as a bare minimum. Any exports are opt-in and (still) not super common. However, any tool that supports them will always prefer them over main/module/browser so there's no reason to drop them.

[btakita]

Hey what does vendorizing mean?

Adding a dependency to the vendor directory to be locked and/or modified. In my case, I'm retrofitting sapper to be more similar to SvelteKit. This involved converting it to "type": "module" & making it's dependency tree compatible with ESM. I have a pnpm multirepo where a custom branch of the vendor/* libraries are added as a git submodule.

I found that having both "main"/"module" and "exports" solves the two problems of compatability with bundt and ESM imports.

[lukeed]

I found that having both "main"/"module" and "exports" solves the two problems of compatability with bundt and ESM imports

Right, they work well together. Bundt can't add exports automatically, because it'd be easy for tlit to guess incorrectly. Plus exports are the public-facing interface for your package, which should always be carefully considered. Finally, the mere addition of exports to a package is a semver breaking change (because Node 13-13.7 incompatibility) -- this is why mri doesn't have them yet.