"it was written by that guy 5 years ago,but he left; so nobody is in charge and nobody understands it anymore, but it still works perfectly and we do not need any upgrades" :-))
"Okay, that's just about the end of your training, any quest-OH, Don't forget, you can never ever turn off the light in the storage closet! It is cursed and the company cannot function while the switch is off. Yes I know there's no lightbulb. No we do not know why. If we knew why it wouldn't be that way."
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.
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 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 `isarray` checked for the prototype). `isarray` failed for the `arguments` keyword, which was needed for variadics before argument spreads were added to the language I believe in ES5.
So of course they don't make sense now. But they were created for a reason. Before even Markov chains were a fad - let alone LLMs - we were trying to be as efficient as possible and maximize code reuse I stead of writing the same helper functions over and over again. That's what you're seeing.
Yes and the critical issue was tree shaking. Nowadays we have tree shaking so it doesn't matter as much but in the past people preferred small single function packages because they had less impact on the download size.
Additional Context: for about two years functional programming was REALLY popular in the Node community. It was a fad to chain tons of tiny functions together, and thus lots of people wrote tons of tiny functions. This is why lodash/fp exists.
I don’t think it ever made sense. Code reuse improves efficiency when the code can be shared in memory, or when it needs to be updated and you only have to change it in one place. JS packages don’t give you sharing beyond what you’d get from copying the code. And these little things don’t need to be updated, and in fact you probably don’t want them to be.
It’s a case of doing something without understanding why it’s done. Packages are good, code sharing is good, so use it for everything. But it misses why they’re good.
I was definitely saying it at the time. But I wasn't embedded in the ecosystem, it was very much "those JavaScript guys are nuts, why would they do this?"
> Ut oh, your code is now broken because isOdd(2^55+1) returns true now...
I think you messed up this example. Whether I literally use "2^55" with XOR or replace it with "2*55", that version of isOdd returns false.
False for isOdd(58) is obviously correct. (Also thanks C for permanently screwing up the precedence of bitwise operations because you didn't want to break some existing programs in 1972.)
False for isOdd(36028797018963970) is also correct, and if you expected to send in a different number the bug is in the "+1" not the isOdd.
But there's no bug in isOdd. You're sending the number 36028797018963970 into it, which is clearly even.
Putting extra code between the parentheses of the function call doesn't make it the function's responsibility. As nice as it would be for debugging if you could stuff your entire program inside of isNaN((function(){ /* your code here */ })()) and force your browser vendor to fix all problems.
Despite what most JavaScript implementations will tell you, 2 to the 55th power is 36028797018963968, and adding one to that value is 36028797018963969. That's clearly odd.
There is no extra code between the parens. I just put them there so there wouldn't be any question as to operator precedence. I do see now that hn ate my double star, but I think you know what I mean since you told me the value that is spits out when you do the exponentiation
You have a plus and an exponentiation in there. That's code.
var n = 2**55 + 1
console.log(n)
isOdd(n)
n is 36028797018963970. isOdd(n) is giving you the right answer. Putting the +1 inside the parentheses and talking about calculators is a sleight of hand that lets you pretend isOdd gets an odd number, but it doesn't. No odd numbers are around by the time isOdd actually does anything.
The problems are in + and/or our expectations of +. It does not output 36028797018963969, and we must acknowledge that.
Everything that touches JavaScript in the corporate world feels broken.
Look at any full stack job post. It’s a mess of tech stack nonsense on the backend for people who are terrified of JavaScript and a layering of framework madness on the frontend for people who are still terrified of JavaScript. So it should be no surprise to see packages like those in common use when people aren’t really writing, or even reading, the real code anyways.
That is just the coding aspect of it. There are many additional challenges to working with a bunch of cowards whose primary job is to pretend to be something they clearly aren’t.
There’s not much evidence these are being used, only that they are dependencies for something else; that’s why the download numbers are so high.
I wouldn’t say it’s broken, I’d say there are tradeoffs, and devs have known this and discussed it since the start of npm or any package manager. You automatically get some bloat when you use other people’s software. That’s the downside. The upside is you don’t have to write the code yourself and you can create things more quickly by not solving problems that others have already solved.
It’s worth noting that AI has some of the same tradeoffs. The quality of what you get is still proportional to your prompting & reviewing effort, and spending low amounts of effort often results in similar amount of bloat.
These packages are basically memes at this point... Those download figures cannot be accurate for real production usage.
I don't believe any programmer is actually using these. isarray and left-pad are at least functions that didn't used to be in the standard library, to slightly excuse them.
I would not bet on that assumption. I have seen some wild code over the years from devs. With 'ai' type coding going on now too you may see them be used even more.
I would've actually thought AI would slightly improve upon this situation. At least in my experience claude seems to write a lot more little utility functions itself rather than reaching for a package from npm to do something. Requiring an `npm install` before getting something working risks triggering a permissions gate.
Opus and fable both are pretty judicious about bringing in dependencies, at least for me. They often argue against and and write even decently large modules to avoid pulling stuff in.
They never install packages for me and love handrolling large amounts of e.g. parsing code where a library exists. I have to keep telling them 'look for a large popular dependency' when they start writing huge functions that obviously already exist.
Was doing something with OSM the other day and Opus basically started reimplementing NetTopologySuite.
Actual programmers do indeed use these packages, and in large numbers. I was in the unfortunate situation a few years ago of hiring a couple of interns (both juniors in a decent CS program) who relied heavily on these types of packages. They honestly thought that it saved them time and they didn’t seem to comprehend the bloat they were adding to otherwise simple code that they could’ve written themselves in 30 seconds. NPM trained a generation of programmers to look for packages rather than learning basic scripts.
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.
> 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.
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.
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.
Free software is Free (and free software is free, libre software is libre, …, where the free/Free/libre/OS/… distinctions are relevant). That does not guarantee continued maintenance for decades, and to expect such is the sort of entitlement that puts some people off sharing their work and playthings.
It doesn't say that depending on it was a bad idea, but that depending on it going forward is a bad idea, and they've gone the extra mile and made an announcement including information about what better alternatives are not available.
Would you prefer it just sat there unfixed and unsupported?
that is NOT what it says - "tell the word that depending on this project WAS a bad idea" ... 'was' - past tense, as in depending on it in the past was a bad idea
We are in the AI era, it doesn't change the fact that investing 1 hrs a month (or even a week) into a long-dead project in a language you no longer use is more investment than 0 hours for the rest of your life.
And yes, if your timeline as a dependency enjoyer is "is this project going to be maintained for 15 years" and you still assumed the answer is yes, it's kind of on you adding a dependency.
Even with AI, the result needs to be reviewed both to make sure it is actually correct in what it intends to do and that it does not have knock-on effects anywhere else. Given the description of the bug I'd think that spinning up the AI and pointing it in the right direction would save no time over just fixing the issue completely by hand.
Fixing the issue could set an expectation in current users of the package that it might get updates going forward, which it obviously won't from this maintainer, potentially reducing any impetus that might exist to move over to something that is a more correct solution these days. Handing over control of the project where it is has risks which are stated in TFA.
So while both fixing and deprecating could have been done, I think the right choice (just mark it as deprecated) has been made. Not fixing the existing bug(s) will not break anything that is using the package any more than it is already broken. If one of the existing issues had potential to be a security issue then I might err more towards fix+deprecate (with big red text included in any announcement of the fix to the effect that this is the last one and future issues won't get resolved upstream).
> Under a comment that reads // Workaround for trailing slashes, my code tacks an “a” onto the path so there’s always a last segment to cut off, then cuts it off with a find-and-replace. When the path ends in a slash, that last segment is just the “a”, and the find-and-replace takes every other “a” in the path with it.
This is top-tier. left-pad levels of "we should just implement trivial functions in our own codebases"
(I do not mean that as a knock on the author - it solved his use case just fine. Everyone who took a dependency on it afterward though...)
I worked there around that time, and a little later. The company had recently ish gotten independent and was actually pretty optimistic. The basic plan was to use the clearly dying dialup business to fund new businesses in media and ads, and there was even hope that the mail and search stuff could be turned around. I think the ads and media stuff broadly worked, most of the media businesses are still going though they were divested by AOL and later Yahoo. The ads stuff did ultimately have a shelf life as the industry consolidated more on Google and Facebook but that was many years away from 2014. Mail and search were eventually merged into their yahoo counterparts post merger.
People at AOL realized how the brand was that of a "wow you still exist" so were pretty good at not putting it too intrusively on new or acquired products. Good for those products, bad for the chances of revitalizing the brand. One of the interesting things post-merger with Yahoo was how much Yahoo people had not adopted the same attitude about their own brand.
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 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.
[…]
Replacement is defined in the github repo, in composer you can only define an replacement package, but there is no real replacement, just alternative ways.
PHP did extensions and PECL modules wrong, due to its roots as a web server language. With managed hosting, often PHP doesn't offer what we might think of as basic functionality, since the admin didn't install/enable it. So it makes sense that these little one-off packages exist to route around snafus.
It's still my favorite language though, since it comes closest to shell language but with C-style syntax (other than maybe Perl, which is a write-only language and hard to read, which unfortunately inspired Ruby to inherit some anti-patterns).
I often dream about writing a modern hacker language that combines the best of everything like functional programming, higher-order methods, const by default, parallelism, sync blocking rather than async nonblocking concurrency, etc. It would also undo the pass-by-reference footguns added by PHP 5+ and return to the pass-by-value copy-on-write style of arrays. That's why I really can't endorse attempts like Hack which just introduce a new standard with its own problems.
The insight being that LLMs work around the limitations of mainstream languages and frameworks, rather than challenging assumptions from first principles and building better foundations.
+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
> Along with the numbers, there were a handful of GitHub issues, including one where joining a path onto a URL with a trailing slash strips every letter “a” out of the path.
In 2009, I started a project, was given a CSV, and in testing the import I created a quick table called "{businessDomain}Temp". Yes, that table is still there, still has the same name, and is load bearing (not in the LLM meme sense, but the business depends on it). Yes, I'm been promising myself I'll fix it one day for just as long.
Considering that every WordPress permalink has a trailing slash by default, and given that WordPress is sort of a big deal in PHP, I'm surprised that it took so long to find that bug.
By Hyrum's Law and the fact that there are 20M installs, we can infer that somewhere, some nitwit is probably using this bug as a handy function for removing 'a's from a string.
I don't think I quite valued the Open Source PHP ecosystem at the time as much as I should have. I have a project that still grabs a ton of installs for some reason (3+ million to date and apparently growing) which is way beyond anything I would have expected.
I am, or was. Once, while living there, I wrote a little C program to read a Visual FoxPro database file and write out PostgreSQL commands to load the data. It was for my employer at the time. We needed it for a migration.
And then, a year later, I got invited to a PostgreSQL convention in Brazil where it was one of the tools being quasi-formally recommended to help migrate the country off of VFP.
The world can feel awfully freaking small sometimes.
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.
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!
Omg, PHP... I ditched this language 7 years ago, because I was fed up with the context switching (fullstack webdev). In the beginning I really was enjoying the gentle slope of learning. I could do a lot without knowing what classes, objects and types are. And I am grateful for this, because thanks to it, now I am here where I can do much more powerful things knowing classes, objects, types and paradigms
There is nothing as permanent as a temporary fix that works.
Nothing is more permanent than a temporary solution.
"it was written by that guy 5 years ago,but he left; so nobody is in charge and nobody understands it anymore, but it still works perfectly and we do not need any upgrades" :-))
"Okay, that's just about the end of your training, any quest-OH, Don't forget, you can never ever turn off the light in the storage closet! It is cursed and the company cannot function while the switch is off. Yes I know there's no lightbulb. No we do not know why. If we knew why it wouldn't be that way."
"No, we don't know why the two positions of the switch are labeled "magic" and "more magic".
"he also left this little BTC mining server in the back room, but it's so nice and warm in there now we just left it running"
temporary solutions often become permanent...
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.
The JavaScript world is littered with stuff comparing to which your patch seems like a complex project. See those examples:
https://www.npmjs.com/package/is-odd
https://www.npmjs.com/package/is-even
https://www.npmjs.com/package/left-pad
https://www.npmjs.com/package/is-whitespace-character
https://www.npmjs.com/package/isarray
what a broken ecosystem.. The crazy thing is not that the package exists, but that it is used by JS devs.
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 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 `isarray` checked for the prototype). `isarray` failed for the `arguments` keyword, which was needed for variadics before argument spreads were added to the language I believe in ES5.
So of course they don't make sense now. But they were created for a reason. Before even Markov chains were a fad - let alone LLMs - we were trying to be as efficient as possible and maximize code reuse I stead of writing the same helper functions over and over again. That's what you're seeing.
Yes and the critical issue was tree shaking. Nowadays we have tree shaking so it doesn't matter as much but in the past people preferred small single function packages because they had less impact on the download size.
Additional Context: for about two years functional programming was REALLY popular in the Node community. It was a fad to chain tons of tiny functions together, and thus lots of people wrote tons of tiny functions. This is why lodash/fp exists.
I don’t think it ever made sense. Code reuse improves efficiency when the code can be shared in memory, or when it needs to be updated and you only have to change it in one place. JS packages don’t give you sharing beyond what you’d get from copying the code. And these little things don’t need to be updated, and in fact you probably don’t want them to be.
It’s a case of doing something without understanding why it’s done. Packages are good, code sharing is good, so use it for everything. But it misses why they’re good.
This is all very easy to say in hindsight. It's missing the context of having been there, I think. Things were just different.
Also, way more fun.
I was definitely saying it at the time. But I wasn't embedded in the ecosystem, it was very much "those JavaScript guys are nuts, why would they do this?"
You want to implement your own is-odd in your code - simple, right? isOdd = (x) => x % 2 == 1
Ut oh, your code is broken for negative numbers now since % isn't a true modulo operator...
Fine then, isOdd = (x) => x % 2 != 0
Ut oh, your code is broken because isOdd("hi") returns true now...
Fine then, isOdd = (x) => if(!isNumber(x)) throw... else return x%2 != 0
Ut oh, your code is now broken because isOdd(2^55+1) returns true now...
Ut oh? I've never seen that, is it variant on uh oh or something else?
It's something I'm fighting for in my own little way.
Everyone does a glottal stop between the "uh" and "oh", so I'm trying to align the spelling
Unlike the guy on him who writes all years with 5 digits like 02026, I have good reasons for my idiosyncracies.
Hm, I would not spell it with a "t" then, but maybe with an apostrophe instead.
"Uh'oh" is more readable in my opinion and won't be mispronou in ced
> Ut oh, your code is now broken because isOdd(2^55+1) returns true now...
I think you messed up this example. Whether I literally use "2^55" with XOR or replace it with "2*55", that version of isOdd returns false.
False for isOdd(58) is obviously correct. (Also thanks C for permanently screwing up the precedence of bitwise operations because you didn't want to break some existing programs in 1972.)
False for isOdd(36028797018963970) is also correct, and if you expected to send in a different number the bug is in the "+1" not the isOdd.
Sorry, it's supposed to be power. So 2**55 in JavaScript
2 to the 55th power is obviously even, so that +1 is obviously odd, but ((2*55) +1) % 2 == 0 in JavaScript.
But there's no bug in isOdd. You're sending the number 36028797018963970 into it, which is clearly even.
Putting extra code between the parentheses of the function call doesn't make it the function's responsibility. As nice as it would be for debugging if you could stuff your entire program inside of isNaN((function(){ /* your code here */ })()) and force your browser vendor to fix all problems.
You should check the math on a real calculator.
Despite what most JavaScript implementations will tell you, 2 to the 55th power is 36028797018963968, and adding one to that value is 36028797018963969. That's clearly odd.
There is no extra code between the parens. I just put them there so there wouldn't be any question as to operator precedence. I do see now that hn ate my double star, but I think you know what I mean since you told me the value that is spits out when you do the exponentiation
> There is no extra code between the parens.
You have a plus and an exponentiation in there. That's code.
n is 36028797018963970. isOdd(n) is giving you the right answer. Putting the +1 inside the parentheses and talking about calculators is a sleight of hand that lets you pretend isOdd gets an odd number, but it doesn't. No odd numbers are around by the time isOdd actually does anything.
The problems are in + and/or our expectations of +. It does not output 36028797018963969, and we must acknowledge that.
IsOdd and IsEven never made sense. They were a badge of shame that said "I have no idea how to program".
Everything that touches JavaScript in the corporate world feels broken.
Look at any full stack job post. It’s a mess of tech stack nonsense on the backend for people who are terrified of JavaScript and a layering of framework madness on the frontend for people who are still terrified of JavaScript. So it should be no surprise to see packages like those in common use when people aren’t really writing, or even reading, the real code anyways.
That is just the coding aspect of it. There are many additional challenges to working with a bunch of cowards whose primary job is to pretend to be something they clearly aren’t.
There’s not much evidence these are being used, only that they are dependencies for something else; that’s why the download numbers are so high.
I wouldn’t say it’s broken, I’d say there are tradeoffs, and devs have known this and discussed it since the start of npm or any package manager. You automatically get some bloat when you use other people’s software. That’s the downside. The upside is you don’t have to write the code yourself and you can create things more quickly by not solving problems that others have already solved.
It’s worth noting that AI has some of the same tradeoffs. The quality of what you get is still proportional to your prompting & reviewing effort, and spending low amounts of effort often results in similar amount of bloat.
PHP devs are happy that npm exists. That way there is always a worse ecosystem down below.
These packages are basically memes at this point... Those download figures cannot be accurate for real production usage.
I don't believe any programmer is actually using these. isarray and left-pad are at least functions that didn't used to be in the standard library, to slightly excuse them.
I would not bet on that assumption. I have seen some wild code over the years from devs. With 'ai' type coding going on now too you may see them be used even more.
I would've actually thought AI would slightly improve upon this situation. At least in my experience claude seems to write a lot more little utility functions itself rather than reaching for a package from npm to do something. Requiring an `npm install` before getting something working risks triggering a permissions gate.
Opus and fable both are pretty judicious about bringing in dependencies, at least for me. They often argue against and and write even decently large modules to avoid pulling stuff in.
They never install packages for me and love handrolling large amounts of e.g. parsing code where a library exists. I have to keep telling them 'look for a large popular dependency' when they start writing huge functions that obviously already exist.
Was doing something with OSM the other day and Opus basically started reimplementing NetTopologySuite.
Major libraries used them so yeah the numbers are real, left-pad was in every react and babel install.
Actual programmers do indeed use these packages, and in large numbers. I was in the unfortunate situation a few years ago of hiring a couple of interns (both juniors in a decent CS program) who relied heavily on these types of packages. They honestly thought that it saved them time and they didn’t seem to comprehend the bloat they were adding to otherwise simple code that they could’ve written themselves in 30 seconds. NPM trained a generation of programmers to look for packages rather than learning basic scripts.
It feels like (to me at least) that the pendulum is swinging back the other way. But maybe this is just my preference.
Whenever I see a npmjs project I nope out of it. I’d rather spend $50 on tokens to reimplement whatever JS slop in Python or Go.
is-even implementation:
> 'use strict';
> var isOdd = require('is-odd');
> module.exports = function isEven(i) {
> return !isOdd(i);
> };
I thought you were joking, but then I checked the code... holy shit, it is real.
Surely the author's gotta be trolling, right?
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.
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.
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.
Others would say pragmatic.
I think it shows a complete misunderstanding on what free software is.
Free software is Free (and free software is free, libre software is libre, …, where the free/Free/libre/OS/… distinctions are relevant). That does not guarantee continued maintenance for decades, and to expect such is the sort of entitlement that puts some people off sharing their work and playthings.
Can you explain what that misunderstanding is?
Deprecation is just a tag. You don't have to respect it. And if you want the project to continue, you can freely fork it.
It doesn't say that depending on it was a bad idea, but that depending on it going forward is a bad idea, and they've gone the extra mile and made an announcement including information about what better alternatives are not available.
Would you prefer it just sat there unfixed and unsupported?
that is NOT what it says - "tell the word that depending on this project WAS a bad idea" ... 'was' - past tense, as in depending on it in the past was a bad idea
Why don't you do it?
We are in the AI era, it doesn't change the fact that investing 1 hrs a month (or even a week) into a long-dead project in a language you no longer use is more investment than 0 hours for the rest of your life.
And yes, if your timeline as a dependency enjoyer is "is this project going to be maintained for 15 years" and you still assumed the answer is yes, it's kind of on you adding a dependency.
Even with AI, the result needs to be reviewed both to make sure it is actually correct in what it intends to do and that it does not have knock-on effects anywhere else. Given the description of the bug I'd think that spinning up the AI and pointing it in the right direction would save no time over just fixing the issue completely by hand.
Fixing the issue could set an expectation in current users of the package that it might get updates going forward, which it obviously won't from this maintainer, potentially reducing any impetus that might exist to move over to something that is a more correct solution these days. Handing over control of the project where it is has risks which are stated in TFA.
So while both fixing and deprecating could have been done, I think the right choice (just mark it as deprecated) has been made. Not fixing the existing bug(s) will not break anything that is using the package any more than it is already broken. If one of the existing issues had potential to be a security issue then I might err more towards fix+deprecate (with big red text included in any announcement of the fix to the effect that this is the last one and future issues won't get resolved upstream).
The cool thing about open source is anyone can fork it and spend their own money asking AI to make a fix.
> check what it proposes
This requires re-learning the language he's out of practice with.
I have written A LOT of PHP in my life. Not so much anymore but I only have fond memories of the community - thanks to folks like you. Kudos.
> Under a comment that reads // Workaround for trailing slashes, my code tacks an “a” onto the path so there’s always a last segment to cut off, then cuts it off with a find-and-replace. When the path ends in a slash, that last segment is just the “a”, and the find-and-replace takes every other “a” in the path with it.
This is top-tier. left-pad levels of "we should just implement trivial functions in our own codebases"
(I do not mean that as a knock on the author - it solved his use case just fine. Everyone who took a dependency on it afterward though...)
Heh, right?
Author: Ugh, this is ugly, but it fixes the specific problem I’m having so I can go on and work on other things.
Author, later: What do you mean, you’re all using this?
hahaha yes, this exactly
We used to work together at AOL. Glad to see you on here; I hope you're doing great!
Reading this threw me back to 2014 - how was working for AOL back then?
I worked there around that time, and a little later. The company had recently ish gotten independent and was actually pretty optimistic. The basic plan was to use the clearly dying dialup business to fund new businesses in media and ads, and there was even hope that the mail and search stuff could be turned around. I think the ads and media stuff broadly worked, most of the media businesses are still going though they were divested by AOL and later Yahoo. The ads stuff did ultimately have a shelf life as the industry consolidated more on Google and Facebook but that was many years away from 2014. Mail and search were eventually merged into their yahoo counterparts post merger.
People at AOL realized how the brand was that of a "wow you still exist" so were pretty good at not putting it too intrusively on new or acquired products. Good for those products, bad for the chances of revitalizing the brand. One of the interesting things post-merger with Yahoo was how much Yahoo people had not adopted the same attitude about their own brand.
Oh cool. Thanks, dude! Feel free to send a message to say hi :)
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:
[1] https://packagist.org/packages/jakeasmith/http_build_url
It would have been nice if a replacement had been suggested.
Replacement is defined in the github repo, in composer you can only define an replacement package, but there is no real replacement, just alternative ways.
Read the linked entry.
PHP did extensions and PECL modules wrong, due to its roots as a web server language. With managed hosting, often PHP doesn't offer what we might think of as basic functionality, since the admin didn't install/enable it. So it makes sense that these little one-off packages exist to route around snafus.
It's still my favorite language though, since it comes closest to shell language but with C-style syntax (other than maybe Perl, which is a write-only language and hard to read, which unfortunately inspired Ruby to inherit some anti-patterns).
I often dream about writing a modern hacker language that combines the best of everything like functional programming, higher-order methods, const by default, parallelism, sync blocking rather than async nonblocking concurrency, etc. It would also undo the pass-by-reference footguns added by PHP 5+ and return to the pass-by-value copy-on-write style of arrays. That's why I really can't endorse attempts like Hack which just introduce a new standard with its own problems.
The insight being that LLMs work around the limitations of mainstream languages and frameworks, rather than challenging assumptions from first principles and building better foundations.
Same. pass-by-value copy-on-write. I always find other languages strange that they do not have this.
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
Didn't know this was a thing. I'll look into it.
> Along with the numbers, there were a handful of GitHub issues, including one where joining a path onto a URL with a trailing slash strips every letter “a” out of the path.
In 2009, I started a project, was given a CSV, and in testing the import I created a quick table called "{businessDomain}Temp". Yes, that table is still there, still has the same name, and is load bearing (not in the LLM meme sense, but the business depends on it). Yes, I'm been promising myself I'll fix it one day for just as long.
Crazy that the bug went unnoticed. So many sites must have been broken by the "a" bug.
It only kicks in in the presence of a trailing / - perhaps this is rare where the function is commonly used.
Considering that every WordPress permalink has a trailing slash by default, and given that WordPress is sort of a big deal in PHP, I'm surprised that it took so long to find that bug.
By Hyrum's Law and the fact that there are 20M installs, we can infer that somewhere, some nitwit is probably using this bug as a handy function for removing 'a's from a string.
https://www.hyrumslaw.com/
https://xkcd.com/1172/
12 years is a pretty good run for a temporary fix!
I don't think I quite valued the Open Source PHP ecosystem at the time as much as I should have. I have a project that still grabs a ton of installs for some reason (3+ million to date and apparently growing) which is way beyond anything I would have expected.
https://packagist.org/packages/tcdent/php-restclient/stats
Are you from Nebraska?
I am, or was. Once, while living there, I wrote a little C program to read a Visual FoxPro database file and write out PostgreSQL commands to load the data. It was for my employer at the time. We needed it for a migration.
And then, a year later, I got invited to a PostgreSQL convention in Brazil where it was one of the tools being quasi-formally recommended to help migrate the country off of VFP.
The world can feel awfully freaking small sometimes.
For real? Wow, i was just referencing the xkcd comic: https://xkcd.com/2347/ what a funny coincidence
Yeah, for real. A friend sent me a copy, captioned “this u?”, and I nearly choked.
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.
Curious: How big is the risk that abandoned extension/fixes turn into a security problem soon in these AI days?
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.
Sometimes not touching something that works is the best way to keep it working!
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!
I love these kinds of stories.
PHP makes me so sad.
Modern PHP is not so bad really.
Why?
Omg, PHP... I ditched this language 7 years ago, because I was fed up with the context switching (fullstack webdev). In the beginning I really was enjoying the gentle slope of learning. I could do a lot without knowing what classes, objects and types are. And I am grateful for this, because thanks to it, now I am here where I can do much more powerful things knowing classes, objects, types and paradigms
PHP kept on getting professional attention and development, and so now it also has all those things you mentioned.
Yes, but also Wordpress still exists and keeps the old ways of doing things.