Define Package Exports in package.json

[FredKSchott]

In Node v13, package exports were introduced as an official way to define sub-paths/modules within your package: https://nodejs.org/api/esm.html#esm_package_exports

in the past, Preact has defined sub-package.json's within the package, to represent each sub-package so that node's resolution logic would automatically load the right files within them. While that should continue to work (I think) this is the new, "blessed" way forward.

I'm getting ready to enable this for Pika CDN, and would like some packages to test against. If Preact enabled this, we could give your users support for preact/hooks, preact/debug, etc. on our CDN.

[JoviDeCroock]

Hey @FredKSchott

I implemented a PR with this, this can be used with pika.dev so should be testable already, thanks for all you are doing in the community! Really admire your work!

#2283

[FredKSchott]

Thanks @JoviDeCroock!

Question: Should we add a "browser" entrypoint at all? Or, alternatively, should the UMD build use a legacy "umd" entrypoint instead, so that browsers can just use the normal "import" entrypoint?

The Pika CDN wants to return ESM, so given your package.json I guess that means I'll want to prefer "import" over "browser". Semantically I'd prefer to use "browser" if it exists, but I guess that runs the risk of others also using it for UMD, based on old habits. Also, Deno can consume Pika, so maybe "import" is better after all.

I don't really have an answer here, just curious to hear what you think. I don't think there actually is a right/wrong answer here yet, you're probably one of the first packages adding this! :)

[JoviDeCroock]

I just felt like if there's import (ESM), require (CJS) then browser would probably refer to a UMD build, not quite sure how the Node team themselves define it since it's not clear from the docs.

[FredKSchott]

Yea, from talking to Myles I believe they want this defined by userland (if its needed at all) and aren't planning to take a hard stance on it.

Personally, i'd recommend "umd" over "browser". My best guess is that web bundlers/CDNs will end up having to choose "browser" over "import", in which case your users will get a worse (less easily optimized/tree-shaken) experience.

[JoviDeCroock]

I understand where you are coming from but umd isn't stated in docs. I understand it's a free choice and actually reasoning further about it import/require and umd are similar keywords. I do think that picking a format that doesn't work in every browser isn't that good for now.

https://caniuse.com/#feat=es6-module still 88% :/

[FredKSchott]

Keep in mind that tooling (bundlers, transpilers, etc) is the most likely consumer of this exports object. If I understand you correctly, the use-case you're imagining is a human one ("I want to load a script via UMD"). I'd argue that a human would be happy (able to read & understand) any of the proposals mentioned above to find the UMD file.

I'm trying, but I can't think of a tooling workflow that would benefit from getting UMD over ESM. Bundlers will have to decide to either ignore "browser" in favor of "import" (not great), or transform "browser" UMD as it bundles (similar to CJS, which can mean no support for named imports / only a default import. also not great).

[JoviDeCroock]

@FredKSchott this was implemented under browser as of the above PR

[FredKSchott]

Woo! Thanks for taking a second look at this 👍