You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
I've just added a new "include" option to esmrouter meanwhile so that we can make it to also serve cherry-picked packages using their "main" field as entry point instead of "browser".
For example, the following will make all "@anyScope/wc-xxxxx" packages to be automatically available client side.
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:
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
The text was updated successfully, but these errors were encountered: