PHPackages                             sdkiller/polyfills-no-more - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility &amp; Helpers](/categories/utility)
4. /
5. sdkiller/polyfills-no-more

ActiveLibrary[Utility &amp; Helpers](/categories/utility)

sdkiller/polyfills-no-more
==========================

Get rid of unnesessary polyfills

1.0.1(1w ago)00BSD-3-ClausePHP &gt;=8.5

Since Mar 10Pushed 1w ago1 watchersCompare

[ Source](https://github.com/SDKiller/polyfills-no-more)[ Packagist](https://packagist.org/packages/sdkiller/polyfills-no-more)[ RSS](/packages/sdkiller-polyfills-no-more/feed)WikiDiscussions master Synced today

READMEChangelog (1)DependenciesVersions (2)Used By (0)

polyfills-no-more
=================

[](#polyfills-no-more)

Many 3rd-party packages tend to overbloat your vendor directory with unnesessary polyfills. Along of wasting extra disk space, your also have to deal with warnings like "Duplicate declaration of function ..." in your IDE and broken autocompletion.

This is mostly common case with Symfony components (or packages, using Symfony components), but not only. While the authors of such packages find "good enough" arguments to explain their approach, IMHO, it is doubtful and outdated. Today it is a very rare case, that your provider does not allow you to install mbstring or iconv extension, etc. With modern containerization techniques you can create any environment nesessary for you project. And arguments like "some projects run php 5.3 but want to use some features from php 8.5" are mostly ridiculous, **You Arent Gonna Need It**. Rare real-world cases of usage of polyfills is not an excuse to explicitly put them into "require" section of that packages.

So, while you are probably will not be able to convince the authors of such packages, you can simply get rid of unnesessary dependencies.

###  Health Score

41

—

FairBetter than 89% of packages

Maintenance98

Actively maintained with recent releases

Popularity0

Limited adoption so far

Community7

Small or concentrated contributor base

Maturity50

Maturing project, gaining track record

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Unknown

Total

1

Last Release

12d ago

### Community

Maintainers

![](https://www.gravatar.com/avatar/18ad4b5af5794d7d17b0a7f169493ff06226f84cadc6c1307f58b1c6f8134108?d=identicon)[zyx](/maintainers/zyx)

---

Top Contributors

[![SDKiller](https://avatars.githubusercontent.com/u/2150916?v=4)](https://github.com/SDKiller "SDKiller (7 commits)")

### Embed Badge

![Health badge](/badges/sdkiller-polyfills-no-more/health.svg)

```
[![Health](https://phpackages.com/badges/sdkiller-polyfills-no-more/health.svg)](https://phpackages.com/packages/sdkiller-polyfills-no-more)
```

###  Alternatives

[develodesign/magento-module-pagebuilder-lazyload-images

Uses the modern browser loading="lazy" attribute on images added via page builder. Can be turned on and off per image as needed.

1645.4k](/packages/develodesign-magento-module-pagebuilder-lazyload-images)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)
