There’s a bit more nuance as to why. It’s not fair to say that the average JS dev is reaching for a package like is-odd/is-even.

Years ago when npm was just getting started there was a lot of experimentation and land grabbing for packages. A few “prolific” developers were pushing these tiny utilities and then using them in their own projects which ended up being required as deps in other projects and then snowballed into is-odd being included in webpack at some point (I think I have that timeline roughly correct).

It’s still a crappy problem for sure but it’s not fair to paint most JS devs with a brush so broad.

I think a lot of things end up that way, just at different timescales. Best we can do is learn from them and start again, IMO - however that looks.

"The road to Hell is paved with good intentions". Still true, probably thousands of years after the sentence was coined.

I’d say the deciding factor is that it has bugs where both fixing and not fixing them can have a negative impact. If there were no known bugs and there was no harm in using it, I’d probably just leave it there and not disturb anything, given that its use is so widespread, and instead merely note in the documentation that its purpose has become obsolete.

From the article:

So I had a decision to make. I could dive back into PHP after almost a decade away, hand the package to one of the people who’d offered, or let it keep sitting there.

We are in the AI era. As a maintainer of an open source project that I haven't touched for years, I would first start by asking an AI to produce a fix for the issue and check what it proposes. This definitely reduces the mental load and risk of breaking an old codebase that so many users depend on.

Deprecating the project is playing the open source game in an other dimension: tell the word that depending on this project was a bad idea in the first place and that everyone should move on. But releasing a fix on a deprecated project is fine too.

So both actions are on different dimensions, this isn't a choice between 2 options.

Reading this threw me back to 2014 - how was working for AOL back then?

It doesn't seem to have gone moldy considering how many people have installed it in recent time.

There is nothing as permanent as a temporary fix that works.

The package is marked as abandoned on Packagist [1]

This package is abandoned and no longer maintained. No replacement package was suggested.

Both adding it as a dependency using composer and installing it from a lockfile results in:

    $ composer require jakeasmith/http_build_url
    […]
    Package jakeasmith/http_build_url is abandoned, you should avoid using it. No replacement was suggested.
    […]
    $ rm -r vendor/
    $ composer install
    […]
      - Installing jakeasmith/http_build_url (1.0.2): Extracting archive
    Package jakeasmith/http_build_url is abandoned, you should avoid using it. No replacement was suggested.
    […]

[1] https://packagist.org/packages/jakeasmith/http_build_url

Reading this made me really nostalgic. I cut my teeth in web/software dev in the Laravel 5.x days, and it's quite jarring comparing the day-to-day we have now with back then!

+1 on this - Jake's done the best thing with deprecating the package (which shows up locally in tooling and will also be surfaced by static analysis tooling (ie security vendors) based on that, but also archiving the repo indicates it to anyone who lands on the repo

Crazy that the bug went unnoticed. So many sites must have been broken by the "a" bug.

Thanks for pointing this out. I used PHP for one of my professional projects and never came through this - maybe because the library was not a part of our codebase.

This article will be very useful for people who might shift back to older PHP versions for compatibility and face it.

Are you from Nebraska?