Open illumincrotty opened 3 years ago
That’s a great question! Where possible, we follow the same spec as Node.js docs when it comes to shipping multiple targets inside one npm package. Specifically, using an exports field is how we determine what loads:
"exports": {
".": {
"browser": "./esm/index.js",
"import": "./esm-node/index.js",
"node": "./cjs/index.js",
"default": "./cjs/index.js"
},
"./feature.js": {
"browser": "./esm/feature.js",
"import": "./esm-node/feature.js",
"node": "./cjs/feature.js",
"default": "./cjs/feature.js"
}
}
Note: .
is for your main package export (functionally equivalent to the "main"
field)
We prefer "browser"
because that’s meant for browser-targeted code, and will be ignored by node. But we will accept "import"
as a fallback, but we don’t recommend that as a first choice because that’s expected to be ESM intended for Node, not the browser.
We do support older methods, such as the technically-incorrect "module"
top-level key, but all the previous methods of doing it are now considered deprecated by subpath exports and that’s our recommended way of packaging modules.
I've been using microbundle which generates several different output formats (ESM, CJS, UMD, and a modern browser ESM). Ideally, I would like he modern browser ESM package to be used when possible but I can't tell which of the formats skypack is using. It either is using the modern one (ideal) the normal ESM one (not ideal) or is using wrappers or conversions to promote the CJS to be used. There is no clarity in the lookup response either. Any help would be appreciated.
View of the various package options