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
If the size the bundle adds to the npm package is an issue, then could it be attached to its corresponding tagged release?
PS. If size is a concern, you may also consider adding an .npmignore file to exclude everything in the repo except the dist/ directory generated by the build tasks.
The text was updated successfully, but these errors were encountered:
@warren-bank, thanks for the request. I would indeed like to do this. We're about to do some major refactoring and will likely reduce the size of the lib substantially in the very near future. At that time, I think you're 100% right we should both include the browser build in the dist, and probably use .npmignore.
My understanding of these CDNs is that they use npm for their upstream.. so anything published to npm is automagically available through their distribution network(s). Some can also download from tagged releases in github repos.
I see you guys are moving fast.. and I absolutely didn't mean to nitpick;
mainly just a combo of (1) eager to use your awesome library and (2) lazy :)
Not nitpicky at all! This is a great suggestion 👍. And yes, I think you're right... just explored this a bit. I'll make sure we add the browser build step to the next published version :)
Hi. I totally get that "Packaging for browsers is currently highly experimental".
But to make it easier to play with.. would there be an objection to updating the
prepublishOnly
npm scriptIf the size the bundle adds to the npm package is an issue, then could it be attached to its corresponding tagged release?
PS. If size is a concern, you may also consider adding an
.npmignore
file to exclude everything in the repo except thedist/
directory generated by thebuild
tasks.The text was updated successfully, but these errors were encountered: