-
-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatically exclude node-specific packages from browser bundlers #564
Comments
I'm not sure what you're asking for here. The only correct thing for a node module bundler to do is provide browser polyfills for node core modules (when feasible), including per-module "globals".
Webpack 5's choice means that every single user of it can't avoid extensive configuration, and it's not up to individual package authors to fix that problem - it's up to webpack's authors. |
To provide browser-specific entry points that don't make use of Node-specific tools.
Yes and no. While they work in the browser, they still need to be bundled (even with browserify), increasing the bundle size (and in this case, configuration). However, in tape’s case:
This means:
One possible improvement would be to exclude https://github.com/substack/tape/blob/a7ca7a308269bc3a250170441553d0321e0d8044/lib/test.js#L317 But it's not a big deal, so I'll close this issue. |
Bundling is a requirement of modern web dev; it's not practical to avoid using one. Bundle size shouldn't matter for a testing tool, even when run in a browser.
|
Where did I say otherwise?
I said that 👇
If you map But then again:
So
|
ah, i misunderstood "they still need to be bundled", my bad. it's not running locally that makes bundle size irrelevant, it's that "it's not for production, it's for dev". Bundle size only matters for production web code. … that's a good point. if I'd be willing to accept a PR for that, since the only cost paid by those using working bundlers is a pretty trivial |
Thanks! However this would need some testing to ensure it works correctly and it's probably not worth the effort at this point, especially since I'm not entirely familiar with that piece of code. |
As discussed in #561 (comment)
I'm opening a specific issue to this because the other one was due to a now-resolved Parcel issue.
In short: It'd be great to automatically offer a browser-only path to ensure:
path
andstream
packagesThe text was updated successfully, but these errors were encountered: