// the take
An unplugin (so it works across Vite, Rollup, webpack, etc. from one codebase) that statically replaces imports of ancient, now-redundant npm polyfill packages — is-number, object-assign, array.prototype.find, left-pad, and dozens more — with native JS equivalents at build time. It's for anyone shipping a library or app whose dependency tree is still dragging in Node 0.x-era polyfills and wants them stripped without touching every consuming package.
Bundler-agnostic via unplugin, so one implementation covers Rollup/Vite/webpack/esbuild instead of maintaining separate plugins. The replacement list is large and specific (50+ named packages) rather than a vague 'optimize polyfills' claim, and it's sourced from es-tooling/module-replacements' maintained mapping rather than hand-rolled guesses. The `replacements` config lets you opt out of specific swaps or supply your own inline replacement code, so you're not stuck trusting every built-in mapping blindly.
The README itself says 'under active development' and lists core roadmap items — tighter nolyfill/module-replacements integration, publish-on-demand infra — as unchecked, so the replacement set and its correctness are still moving targets. Coverage is a fixed allowlist: anything not on the list (the README calls out node.extend, extend-shallow, xtend, defaults explicitly) passes through untouched, so you can't assume your whole polyfill footprint gets cleaned up. Custom replacements are supplied as raw code strings injected into the build, which is a footgun for subtle behavioral mismatches (NaN edge cases, plain-object prototype checks) that won't surface until runtime. Real-world adoption is thin — only two linked consumers (nuxt/cli, unjs/jiti) and 218 stars — so there isn't much production mileage behind the replacement logic yet.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →