That's a common misconception but browser field should not be used for UMD bundles. It's an alias field that should contain alternative implementations browser-specific implementations.
To put more context around it - you want modern bundlers (such as webpack) to pick up contents of module field because it refers to file authored in ES modules and thus supporting tree-shaking etc. But by specifying a browser field you make it more important for a bundler like webpack and it picks it up instead of the module one. So many consumers of your library end up with unoptimized bundle & extra bytes if they use ur dependencies somewhere else too (because UMD bundle contains copy of them).
If you have any questions regarding this, please just ask - I'm happy to help and to clarify this more if needed :)
That's a common misconception but browser field should not be used for UMD bundles. It's an alias field that should contain alternative implementations browser-specific implementations.
To put more context around it - you want modern bundlers (such as webpack) to pick up contents of module field because it refers to file authored in ES modules and thus supporting tree-shaking etc. But by specifying a browser field you make it more important for a bundler like webpack and it picks it up instead of the module one. So many consumers of your library end up with unoptimized bundle & extra bytes if they use ur dependencies somewhere else too (because UMD bundle contains copy of them).
If you have any questions regarding this, please just ask - I'm happy to help and to clarify this more if needed :)