Requirements for consuming environment;

• Node version > 12
  • this major introduced the exports field.
• Typescript moduleResultion set to "node16", "nodenext" or ideally, "bundler".
  • These are the only modern moduleResultion options which makes typescript support exports field

Recomendations:

• A dev environment which can optimize/bundle ESM based deps if needed, like Vite.

Thoughts on publishing a package in 2023

First of all, wtf, haha. Why is this so god damned hard.

Ditching bundling as esm is the de facto module standard alleviates a TON of headaches. I've come to the conclusion that it is the consuming environents responsibility to optimize deps if necessary, just as vite does. Bundling just to support commonJS adds a ton of config headaches that are simply not worth the tradeoff.

This package uses SWC to compile. SWC is used over ESbuild for its ability to include just a directory which it recreates in a distribution-folder. ESbuild needs explicit inputs and outputs glob patterns in a flat manner. Neither SWC nor ESbuild generates declaration files. This will as of now still need to be produced by tsc. SWC will eventually support this through STC (Speedy type checker).

Typescript doesn't seem to understand the package.json exports field very well. The consuming typescript environment needs very spesific conditions to properly honor exports field. TS must be v5 or newer w/ moduleResolution set to bundler.

Typescript support for package.json exports has appearantly existed before v5 through moduleResultion set to e.g. "nodenext", but that necessitates some other ugly codebase changes in the consuming environment

The exports field has support for subpath patterns with catch all path segments. This seems to be very poorly supported by typescript. The ability to reach modules through subpaths is a good emerging pattern, as explained by a rollup maintainer.

As of now, because of typescript, it seems best to manually list each entrypoint as en exports entry. Even though it creates package.json bloat and is a small maintenance burden. This seems to be an intentional limitation due to performance.

Things that unfortunately seem unecessarily difficult or impossible

Instead of having peer deps, it would be nice for e.g. a utility package to just re-export packages. This alleviates package.json dependency bloat in the consumer allows for pinning deps to spesific versions, peer-deps by design must be relatively loose to not be overly annoying to use. Also separation of concers as said packages are reached from a meaningful group.

• esm re-exports may need maintaing and is only easy for packages with a single entrypoint. Still seems to be the best options because it presevres auto-imports.

• Just shipping node modules directly (preferrably w/ different name) and exporting that works, but auto imports break.