Improve package publishing

Suggestions:

1. The exports field shouldn’t stripped from the published package.json and no index.mjs file is included. @n1ru4l I found that you raised this issue earlier, (though not sure why it was closed) https://github.com/kamilkisiela/bob/issues/16
2. Don’t bundle. Publish as commonjs unbundled with both commonjs and ESM entrypoints. This can also allow consumers to deep import files rather than via their named exports. This should be encouraged in the documentation. The entrypoints can remain mostly for static analysis.
3. As an alternative, perhaps consider perhaps only publishing ESM. https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c

[n1ru4l]

If you want to reduce memory usage you can still bundle your server code and drop unused code via tree shaking. I don’t see why deep imports (which limit me as a library maintainer), should take care of this instead.

I think importing from CDN and causing request waterfalls is also something that should be avoided for production usage (by using a bundler), for development/demos the additional loaded code won’t be a dealbreaker.

The dual package hazard is only introduced if people decide to only ship ESM or commonjs which basically means “I don’t care about library consumers” to me.

If a package has zero dependencies (or all dependencies of that package are ESM only) I agree that only shipping ESM is totally legit. But as soon your library has dependencies you should ship both commonjs and ESM in order to avoid the dual package hazard.

[dburles]

1. There is an exports field in the package.json https://unpkg.com/browse/@n1ru4l/json-patch-plus@0.1.2/package.json Can you clarify what you mean?
2. I dont like that as it does not allow renaming and moving internal stuff without making it a breaking change. What are the actual benefits of doing that?
3. Only shipping ESM disrupts the ecosystem. Supporting both is not hard. I ao ne point in dropping commonjs support right now.

1. I realised that I was on earlier versions of a couple of packages, which didn’t include the exports field (https://unpkg.com/browse/@n1ru4l/graphql-live-query-patch-jsondiffpatch@0.4.0/package.json). I wasn’t aware that it had already been addressed. Great!

2. On deep imports, the advantage is that users won’t be importing anything they don’t need, saves memory on the server and negates the need to tree shake if bundling on the client. It also better supports browser URL imports over CDN since users won’t be downloading the entire API (Edit: note that this requires publishing files as ESM, though some CDN’s can convert to ESM such as https://esm.sh/).

3. Supporting both is kinda hard, currently these packages all suffer from the dual package hazard, see here for an explanation.