How do you stop a bundler from pulling in Node polyfills for one import?

programming web dev
1

Hey folks, I’m wiring up a small web app and I’m trying to keep the bundle lean, but one dependency keeps dragging in Node-ish polyfills and my chunk size jumps hard. The failure mode is it “works” in dev, then prod gets bloated and tree-shaking feels like it gives up.

// vite/rollup-ish setup
export default {
  optimizeDeps: {
    exclude: ["some-lib"],
  },
  resolve: {
    alias: {
      // I only need a tiny helper, but it seems to pull in the whole package
      "some-lib": "some-lib/dist/index.js",
    },
  },
};

What’s the cleanest way to force the browser-safe entry (or a subpath) so the bundler doesn’t inject Node polyfills, without forking the dependency or breaking future updates?

1 Like
2

That alias is almost certainly the culprit. When you alias "some-lib" to a concrete file path, you’re basically opting out of the package’s own entrypoint logic (exports conditions, browser field, etc. ). Rollup/Vite can’t pick the browser-safe branch anymore, so you end up on whatever dist/index. js happens to import… and then the polyfill parade starts (process, buffer, sometimes stream). The cleanest pattern is: don’t alias the bare specifier, and don’t “pin” the root. Either import a documented subpath that’s already browser-safe, or create a tiny local wrapper module and only ever import from that wrapper so you’ve got one place to change later when the package reshuffles.

 // vite.config.js (vite/rollup-ish)
 export default {
   optimizeDeps: {
     exclude: ["some-lib"],
   },
   resolve: {
     // Let Vite/Rollup evaluate conditional exports normally.
     // Only set this if you have a reason; Vite already prefers browser in many cases.
     conditions: ["browser"],
     alias: {
       // Avoid aliasing the bare specifier:
       // "some-lib": "some-lib/dist/index.js",
     },
   },
 };

Then in your app code, target the smallest stable entry the library actually supports (their docs/exports map should tell you what’s valid):

 // Prefer a supported subpath export (example)
 import { tinyHelper } from "some-lib/helpers/tiny";

And if you want future-proofing without forking, the wrapper approach:

 // src/vendor/someLibTiny.ts
 export { tinyHelper } from "some-lib/helpers/tiny";


 // elsewhere
 import { tinyHelper } from "@/vendor/someLibTiny";

One thing I’m not 100% sure about without seeing the actual package is whether it’s using exports properly or relying on the legacy browser field only (some libs still do). Either way, aliasing the root to a file path is the fast track to bypassing the browser condition and getting Node-y imports pulled into your graph.