My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it
summary
A developer created a small PHP polyfill in 2014 to solve a specific migration issue at AOL, which unexpectedly grew to nearly 20 million installs through various plugins and operating systems. Despite its widespread use, the author decided to deprecate the package rather than maintain it or hand it over to a new maintainer. This decision prevents potential security risks associated with unvetted maintainers and encourages users to migrate to modern, standards-compliant URI libraries. The project serves as a reminder of how temporary code can unexpectedly become critical infrastructure.
key points
- The package became an accidental dependency for major projects like the WPML WordPress plugin and Debian/Ubuntu distributions, leading to massive installation numbers.
- A long-standing bug in the path-handling logic caused characters to be stripped from URLs, illustrating the danger of relying on outdated, simplistic shims.
- Deprecating the package instead of transferring ownership avoids the security risks highlighted by the xz Utils backdoor, where attackers target widely used but poorly maintained libraries.
who should read it
Software developers and system administrators who manage legacy dependencies or maintain open-source libraries.
discussion positive
consensus
Commenters generally agree that temporary software fixes often become permanent, leading to legacy code that nobody understands but still functions. This trend is particularly criticized in the JavaScript ecosystem, where a proliferation of tiny, redundant packages like 'is-odd' reflects a historical preference for extreme modularity and a lack of fundamental programming knowledge among some developers. While some defend these packages as necessary for early JS environments or as a result of dependency chaining, the overall sentiment is that this approach created unnecessary bloat.
top insight
The prevalence of tiny NPM packages was not just a result of poor programming, but a driven by historical constraints like the lack of native functions (e.g., Array.isArray) and the absence of tree shaking, which forced developers to use small packages to minimize download sizes. This perspective shifts the blame from 'lazy' developers to the architectural limitations of the early Node.js ecosystem.
Generated by an LLM from the article and thread. Check the sources before relying on it.