Remove deprecated @babel/polyfill and core-js dependencies

[Copilot]

Investigates and removes @babel/polyfill and core-js per #567. Both were dead dependencies - never imported anywhere in the codebase.

Findings

• Not imported: No src/ or test/ files import @babel/polyfill or core-js
• Babel config was no-op: .babelrc used useBuiltIns: "entry" which only works with explicit import "core-js/stable" at entry points - none existed
• Async/await handled separately: @babel/plugin-transform-runtime + @babel/runtime already injects regenerator-runtime
• Zero bundle impact: dist/quagga.min.js remains 134 KiB before and after

Changes

• Remove @babel/polyfill from devDependencies
• Remove core-js from devDependencies
• Update .babelrc to use useBuiltIns: false (since polyfills aren't used)
• Update DEPENDENCIES.md to document removal rationale

Benefits

• Eliminates deprecated package warning on npm install
• Removes transitive [email protected] (deprecated, known performance issues)
• Cleaner dependency tree

Browser Coverage Note

The current webpack target "last 2 versions" provides ~65% global coverage (includes obsolete browsers like IE 10/11). Modern browsers in that list (Chrome, Firefox, Safari, Edge) all support ES6+ natively, so polyfills weren't needed anyway. Alternative targets like "defaults" (~87%) or "> 0.5%, not dead" (~85%) could be considered for wider coverage without requiring polyfills.

• Fixes Investigate safety of removing babel polyfill? #602

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Investigate safety of removing babel polyfill?</issue_title>
<issue_description>Per #567

... is it safe to attempt removal of @babel polyfill? What do we lose or gain by doing so?

</issue_description>

<agent_instructions>Investigate upsides and downsides of removing babel polyfill dependency, and what is necessary to do so. </agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Investigate safety of removing babel polyfill? #602

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[rollingversions]

There is no change log for this pull request yet.

Create a changelog

[ericblade]

@copilot I see that one of the documentation notes you removed said "Should migrate to core-js@3 + regenerator-runtime" ... is that advice still valid? like, do we even need core-js given that we are presently using typescript? or if we are using core-js does that allow me to use a more modern typescript output target? Or ... what? I'm slightly unsure. I'm guessing we can remove this one, simply because it's been years since corejs@2 was current, and probably everything it fills in is supported in every browser that still exists?

[Copilot]

@copilot I see that one of the documentation notes you removed said "Should migrate to core-js@3 + regenerator-runtime" ... is that advice still valid? like, do we even need core-js given that we...

Good question! The advice to "migrate to core-js@3 + regenerator-runtime" was the official Babel recommendation when @babel/polyfill was deprecated, but in your case it's not needed because:

1. core-js@3 is already in devDependencies (v3.46.0) and the .babelrc references it with corejs: { version: 3 }, but it's effectively unused since useBuiltIns: "entry" requires explicit imports that don't exist in the codebase.

2. TypeScript doesn't provide polyfills - TypeScript only transpiles syntax (like async/await to generators), it doesn't polyfill APIs (like Promise.finally(), Array.includes(), etc.). However, those APIs are already supported in all modern browsers, and you're targeting "last 2 versions" in webpack config.

3. regenerator-runtime is handled separately - The @babel/plugin-transform-runtime + @babel/runtime combo already injects regenerator-runtime for async/await, which is the main thing most projects need.

Could you remove core-js entirely? Probably yes, since:

• It's not actually imported anywhere in src/
• The Babel config with useBuiltIns: "entry" does nothing without explicit import "core-js/stable" imports
• Modern browsers (last 2 versions) support ES6+ APIs natively

Would you like me to test removing core-js as well, or keep it as-is since it's not causing any issues?

[ericblade]

@copilot yeah, try removing that, and let's see what happens

does "last 2 versions" make sense? does that get us like 95% or more of users? or should we be targeting a little wider?

[Copilot]

@copilot yeah, try removing that, and let's see what happens

does "last 2 versions" make sense? does that get us like 95% or more of users? or should we be targeting a little wider?
...

Removed core-js in aeda83f. Build passes, bundle size unchanged (134 KiB minified).

Browser coverage for "last 2 versions":

• Current target: 65.03% global coverage
• Includes obsolete browsers (IE 10/11, BlackBerry 7/10)
• "defaults" query: 86.77% (recommended: > 0.5%, last 2 versions, Firefox ESR, not dead)
• "> 0.5%, not dead": 85.09%

The 65% coverage sounds low, but it's because "last 2 versions" includes dead browsers (IE, BB). The modern browsers in that list (Chrome 141-142, Firefox 143-144, Safari 26, Edge 141-142) all support ES6+ natively, so polyfills weren't needed anyway.

If you want to widen coverage without polyfills, consider changing the webpack config target from "last 2 versions" to "defaults" or "> 0.5%, not dead". The modern output should still work since ES6 is universally supported now.