Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

jakeasmith.com

Post reply on HN
Print view View original

21–30 of 93 posts

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#21

Post by toyg »

b112 wrote: post #18
junon wrote: post #17

Earlier quoted context omitted.

I feel like I have to remind people of this quite often, but the history is such that npm was lightweight at one point, bundling wasn't a thing, and while `isodd`/`iseven` are of course silly, things like `isarray` were not functions that existed back then (we didn't have Array.isArray). `typeof [] === 'object'` in JS, so e.g. my package `is-arrayish` checked for a similar structure to an array (whereas Id guess `isa…

I hate to bring politics into such discussions, but this thought struck me as funny. The hubris of humanity... what you're describing is akin to the US Constitution and the Founding Father's goals, ending in Donald Trump. Node is the same horror. Nice ideas, great premise, and all turned to garbage in the end.

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

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#23

Post by samayashar »

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.

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#24

Post by dolmen »

jakeasmith wrote: post #2

Author here, happy to answer any questions. I never imagined a polyfill for http_build_url would gain so much traction. After 12 years, deprecating it feels like the right move, especially given the new options from the community and PHP itself.

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.

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#26

Post by jamietanna »

AltruisticGapHN wrote: post #16

Should the repo be archived? I rarely see people use that feature yet tons of repos on Github are essentially dead.

+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

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#27

Post by duskdozer »

hdjrudni wrote: post #10
Codefrontier wrote: post #4

Love you kept it alive this long

It hasn't been updated in 11 years. Not sure I'd call that "keeping it alive".

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

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#28

Post by jjice »

dolmen wrote: post #24
jakeasmith wrote: post #2

Author here, happy to answer any questions. I never imagined a polyfill for http_build_url would gain so much traction. After 12 years, deprecating it feels like the right move, especially given the new options from the community and PHP itself.

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…

The man released a fix twelve years ago for free. If someone is really depending on this, they can fork it themselves. I'd argue that that's the beauty of open source, rather than a downside.

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#29

Post by mech422 »

dolmen wrote: post #24
jakeasmith wrote: post #2

Author here, happy to answer any questions. I never imagined a polyfill for http_build_url would gain so much traction. After 12 years, deprecating it feels like the right move, especially given the new options from the community and PHP itself.

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…

The down vote was me - I really think calling deprecating a project after a decade+ telling the world 'depending on this project was a bad idea' is tone deaf.

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#30

Post by Timwi »

TimWolla wrote: post #8
laruss5 wrote: post #7

For a package with that kind of install base, is there a final release that prints the migration options in a deprecation notice? People will find it years from now through old Stack Overflow answers.

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…

It would have been nice if a replacement had been suggested.
Post reply on HN