I would propose to add the "browser" field in package.json files in addition to the "main" field having the browser field announces it a package suitable for the browser.

Moreover it could point to a minified version as I've seen exists on several wc's while the "main" field is pointing to a non minified one.

Notes

According to package.json documentation at NPM Docs:

If your module is meant to be used client-side the browser field should be used instead of the main field. This is helpful to hint users that it might rely on primitives that aren't available in Node.js modules. (e.g. window)

Additionally, the presence of the browser field would make easier to serve them client side with tools like esmrouter for Express applications (hope you don't see this as spam: I think that concept could be replicated to other stacks...)

As an example, to get one's hands dirty with wc-markdown, would be as easy as typing:

npx xprgen --esmr -i @vanillawc/wc-markdown myApp

...and then import by that name client side.

References

• browser field - Browser field specification at NPM Docs' package.json documentation.

• esmrouter - Make browser-enabled npm packages directly available client side (for Express apps).

• xprgen features