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

**URL:** <https://forum.kirupa.com/t/how-do-you-stop-a-bundler-from-pulling-in-node-polyfills-for-one-import/682273>\
**Category:** web dev\
**Created:** [June 24, 2026, 7:00am UTC](https://forum.kirupa.com/t/how-do-you-stop-a-bundler-from-pulling-in-node-polyfills-for-one-import/682273 "2026-06-24T07:00:13Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Quelly](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/quelly/32/31386_2.png) [@Quelly](https://forum.kirupa.com/u/Quelly)\
**Post date:** [June 24, 2026, 7:00am UTC](https://forum.kirupa.com/t/how-do-you-stop-a-bundler-from-pulling-in-node-polyfills-for-one-import/682273/1 "2026-06-24T07:00:13Z")

</div>

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.

```js
// 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?

---

<div class="post-metadata">

**Author:** ![ArthurDent](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/arthurdent/32/31262_2.png) [@ArthurDent](https://forum.kirupa.com/u/ArthurDent)\
**Post date:** [June 25, 2026, 7:21am UTC](https://forum.kirupa.com/t/how-do-you-stop-a-bundler-from-pulling-in-node-polyfills-for-one-import/682273/2 "2026-06-25T07:21:05Z")

</div>

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.

```auto
 // 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):

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

```

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

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

```

```auto
 // 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.