Thank you for this PR, but I think it adds too much complexity compared to#243. Instead of one entry point (lib/index.js) there are now two (lib/index.js andlib/esm.js) as well asdist/index.mjs which is redundant. Removingdist/index.mjs is a breaking change, so you end up with two ESM compatible entry points that do the same thing, one used by Node.js and the other used by webpack.

There is also amodule field and anexports field that each point to different entry points, which confuses things further.

You've also removed thebrowser field frompackage.json, which ensures that certain polyfills are included. Andlib/esm.js cannot be used by browsers because bothparse.js andstringify.jsrequireutil.js.

esm.js is used only for building proper exports in dist/index.mjs because generating exports from commonjs is not reliable and may change with rollup upgrade. I do not suggest to remove dist/index.mjs.

"module" is bundler specific field. "exports" is node specific way to support es modules natively. Probably only webpack 5 support both them yet.
https://nodejs.org/api/packages.html#packages_conditional_exports

Here's example
https://unpkg.com/browse/nanoid@3.1.12/package.json

"browser" field should not just point to umd. Bundlers prefer "browser" field over over "module" when specified as a string. This makes "module" field useless in this case. See the correct use case for "browser" fieldhttps://github.com/visgl/react-map-gl/blob/master/package.json#L17-L25