[HN Gopher] Lodash just declared issue bankruptcy and closed eve...
___________________________________________________________________
Lodash just declared issue bankruptcy and closed every issue and
open PR
Author : omnibrain
Score : 84 points
Date : 2023-09-16 20:32 UTC (2 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| smitop wrote:
| The bigger news is that Lodash is migrating from Node.js to Bun:
| https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...
| firtoz wrote:
| Woah.
|
| I was starting to get excited about migrating my packages to
| Bun, but hesitating because I was afraid of compatibility or
| whether Bun is really here to stay or not - I have been
| slightly burnt by "Modern Yarn"; but honestly, seeing lodash
| make the leap makes me want to consider it more seriously now.
| steve_adams_86 wrote:
| I'm a yarn burn victim as well, and it has made me a lot more
| apprehensive about fundamental decisions like these. They
| seem so promising and your research seems to check all/most
| of the boxes... Then you get Yarn 2/3
| SeanAnderson wrote:
| I am so conflicted on this! On the one hand, I fucking love it.
| Who hasn't experienced a backlog grooming session where you know
| it's impossible to reach the end of the backlog and you just sort
| of go along with the process of scraping from the top. There's
| definitely something miserable about that feeling.
|
| On the other hand, it's not like the issues are gone, they're
| just tagged differently, and if everything is just tags and
| organization then why not go with the flow rather than exerting
| control in an attempt to achieve this pseudo-perfect empty issue
| list. There's gotta be benefit in keeping those notes around and
| visible, right? Sort of feels like deciding to throw something
| out of your house while deep in a cleaning spree even though your
| subconscious is (reasonably) nagging at you to hold onto it
| because you might need it in the future.
|
| On the whole I think I'm for it, though, if anything just for the
| cathartic release and presumed re-invigoration towards new
| issues.
| layer8 wrote:
| As a user, I find such a "cleanup" problematic if it means
| closing the issue. If the issue still exists in the product, it
| should remain open, for documentation, and so that users
| running into it can easily find it and add to it. I find it
| more honest if a project acknowledges that the issue exists by
| leaving it open.
|
| As a developer, I'd rather use a filter to hide older non-
| critical issues, if I'm bothered about seeing the amount of
| issues.
| eikenberry wrote:
| Closed doesn't have to mean resolved and the tickets would
| still be available either way. Closed is IMO ideal for these
| tickets as ultimately it means that they aren't being looked
| at.
| layer8 wrote:
| Closed implies that a decision has been made that the issue
| is somehow not worthy of consideration anymore. That's what
| bugs me as a user.
|
| Whether any given ticket is being looked at can change over
| time. Closing it is a way to drastically reduce the
| likelihood that it is being looked at. As a user, I see no
| good reason why that should be done, in particular when it
| is applied across the board without considering the
| individual issue.
| eternityforest wrote:
| But they _should_ be looked at. They aren 't because we
| don't have infinite time every day to look at issues.
|
| If those issues are still a problem nobody will find them,
| they'll make new issues and lose all the previous history,
| unless the UI is designed to support automatically
| suggesting reopening an old issue instead.
| jrmg wrote:
| It's not necessarily true that they 'should' be looked
| at. Most old projects that follow the 'never close
| without verification' philosophy end up, eventually, with
| a majority of open issues not actually reflecting the
| current state of the project.
|
| A middle-ground might be to leave open the issues with
| recent activity, with the idea being that at least the
| ones that are affecting people the most are not swept
| under the rug.
| joepie91_ wrote:
| > Most old projects that follow the 'never close without
| verification' philosophy end up, eventually, with a
| majority of open issues not actually reflecting the
| current state of the project.
|
| There's a crucial question here that I find not enough
| people ask themselves: _does that actually matter?_
| Denvercoder9 wrote:
| Lots of projects on GitHub (not sure about lodash)
| automatically lock closed issues so you can't comment on it
| anymore. That closes an avenue for those that are impacted
| by the issue to discuss fixes, workarounds and
| alternatives.
| gochi wrote:
| Closed doesn't mean resolved, it means closed. Closing issues
| just shifts them to another tab, doesn't remove them
| entirely. What you propose, a filter to hide these, is
| exactly what has been done just through the official
| open/closed filters.
| layer8 wrote:
| This is not accurate. When searching for issues, users
| won't find closed issues by default. When issues are
| linked, closed issues are rendered differently (struck
| through). You can't comment on them anymore without
| reopening them, and reopening them is often discouraged or
| not enabled at all. It is a drastically different state.
| etler wrote:
| For a bit more context, the creator is doing a full rewrite.
|
| I think it would probably have been cleaner to release the
| rewrite first, then close all the old issues as deprecated. You
| could isolate the rewrite branch issues with a version tag.
| Closing then while the new version isn't done may lead to
| contributers opening new issues on the old version without
| realizing that it is no longer supported.
|
| But he's not just ignoring the issues and leaving problems in
| the code base, the entire project is getting a refresh.
|
| https://twitter.com/jdalton/status/1571863497969119238
| brailsafe wrote:
| I like it, it's the "put everything in a giant mailbag, label
| it, and dump it in a storage locker" approach. If the issues
| are still relevant, they can be resurfaced.
| sneak wrote:
| What percentage of the now closed bugs still extant in the
| current version will be reimplemented in the rewrite?
| vosper wrote:
| What is issue bankruptcy? Is it declaring that you don't have the
| resources look at the issues?
|
| It seems much better to tag them like Lodash has done rather than
| let open issues pile up like many other low- or no-resource
| projects do.
| klardotsh wrote:
| In IRL bankruptcy you declare you can't possibly pay back your
| creditors and lose "most" non-trivial assets as they're
| liquidated off to attempt to make a few pennies for those
| creditors as you rebuild your life from 0.
|
| Lodash just decided to rebuild from 0 - literally, actually,
| since it's a rewrite, but especially in the bug tracker sense
| of the word.
| davidmurdoch wrote:
| Relevant recent tweet from lodash's creator:
| https://x.com/jdalton/status/1701015897702572335?t=YLClO1zWa...
| pxue wrote:
| select all open issues,
|
| Tag: won't fix, close.
|
| Restart cycle.
| romellem wrote:
| John-David Dalton, the lodash author, wrote [this last year][1]:
|
| > For the lodash rewrite I'm declaring tech debt bankruptcy.
| Starting from scratch with TypeScript and Rollup. No FP wrappers.
| That fad is over. RIP your co-workers if you introduced that
| headache into your codebase. Definitely not team or human
| friendly.
|
| Don't know if he's sticking to this 100% but seems pretty close.
|
| [1]: https://twitter.com/jdalton/status/1571863497969119238
| gorgoiler wrote:
| What were FP wrappers and what was the fad?
| stolenmerch wrote:
| "Auto-curried function style (reversed arg) wrappers"
|
| https://twitter.com/jdalton/status/1571870137690591236
| legulere wrote:
| And what is that?
| janehdoch wrote:
| [flagged]
| gorgoiler wrote:
| Specifically I don't know, though I do know what currying
| is. This auto-currying thing sounds like a reaction
| against some parts of JavaScript where you can get burned
| by default arguments.
|
| A curried function is like a partial application for each
| argument. If _mul:=(a,b)= >a*b_ then currying would be
| being able to say _double:=mul(2)_. Currying everything
| and requiring all function calls to have one parameter
| per call -- _six:=mul(2)(3)_ -- might have some benefit
| in avoiding bugs.
|
| Generally speaking though my hunch is that the lodash
| author grew tired of the project's focus on meta
| programming: noodling around with JavaScript using
| programming paradigms that hinder rather than help its
| users. Dropping the noodling and focusing on features is
| a "back to basics" moment, if you will.
| tibbon wrote:
| I'm truly under-educated on JS issues. What is wrong with FP in
| this context?
| rutierut wrote:
| Nothing really but besides it not working with typings too
| well it's just quite uncommon. I love it personally but
| strictly use it on personal projects, this is really not
| something one should introduce to a project that multiple
| people are working on.
| beebeepka wrote:
| I never liked lodash, even when when it was new. These days I
| just laugh when people tell how great it is.
|
| Useful? Sure. But if you care about performance and simplicity,
| just spend a day or two writing your own versions of the things
| that you need. Or, if rolling home made is not to your liking, go
| with ramda.
|
| Edit: downvote vall you want but at least have a look at lodash
| internals just in case. What an overcomplicated mess. It's old,
| really old.
| ChrisMarshallNY wrote:
| _> at least have a look at lodash internals just in case._
|
| I think that's the issue. The author seems to agree with you,
| and is rewriting it.
|
| I don't use JS or Lodash, so I have no feedback on the
| particulars of this instance.
|
| However, I am in the final phase of a "Declare bankruptcy, hit
| reset" rewrite of the app I'm developing, and I'm really,
| really glad that I did it.
|
| I did encounter many of the same issues, as I proceeded on the
| rewrite, but I was prepared, and I feel I handled them far more
| elegantly than the original.
|
| But that was a luxury that I had, as we are not doing the MVP
| thing. If you are dealing with a shipped app, it's quite a
| challenge, to do the bankruptcy thing.
| paulgb wrote:
| Are there functions where the performance is significantly
| worse than what you could write on your own?
|
| Not a rhetorical question. I don't use lodash but as a
| primarily non-JS dev I've referred to the source some times
| when I'm writing JS as a reference for the idiomatic way to do
| simple things.
|
| I've found some weird things, like isEmpty is technically O(n),
| but this turns out to be a limitation of JavaScript rather than
| a lodash issue.
| eyphka wrote:
| There are a couple of weird things in my experience, like the
| old implementation of zip, but by and large it was mostly
| either restrictions of js itself or browser implementations
| of js.
|
| Lodash has and still is a good standard / reference for these
| simple operations imo.
| SparkyMcUnicorn wrote:
| Looking at the internals is often why I choose to use it. It
| catches edge cases I might not think of, and the performance
| tradeoffs have been negligible to none.
|
| I don't use it for everything, and definitely try to use native
| and/or narrower scope methods when it makes sense, but it's
| saved me a lot of time and headache throughout the years.
| K0balt wrote:
| He's rewriting from scratch in typescript.
| xwdv wrote:
| I wonder if for some very popular open source libraries, charging
| a small fee to report an issue might be some kind of viable
| business model, or at least a way to prevent too many issues. You
| might say this will result in people not reporting legitimate
| issues, but as we can see in this case it's not the end of the
| world.
| CodeWriter23 wrote:
| Everyone gets a feature!
| omnibrain wrote:
| They tagged 363 issues with "issue bankruptcy" and closed them:
| https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl...
|
| Same for 325 PRs:
| https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...
| Supply5411 wrote:
| Issue bankruptcy is real. Speaking from personal experience, at
| some point maintaining OSS is incompatible with living in the
| real world. The work is free and often thankless (but not
| always). The problems are complex and compete with real world
| responsibilities, like work, family, rest. People get pissy and
| regularly want to argue with you or read the docs for them. It
| also carries enormous responsibility if your OSS is popular.
|
| I am anticipating a huge collapse in the OSS ecosystem as the
| people who drive them say "fuck it" and walk away for more
| important things.
| monksy wrote:
| I wonder if this would be a thing if everyone who created an
| issue had to reproduce it via a test.
| pscanf wrote:
| Well done!
|
| Looking at the first few PRs in the list, you can see things
| like:
|
| - Adding a word in a comment.
|
| - Adding config files to self-promote dev services.
|
| - Switching from using var to let.
|
| - Changing well-established behaviours of core functions.
|
| - Removing semicolons.
|
| - ...
|
| I'm sure most of those were opened with good intentions of
| improving the library, but at some point for the maintainer they
| just become spam (or worse, a growing burden that makes you feel
| guiltier and guiltier for not giving it attention).
|
| Celebrities hire bodyguards and fly first class (or private) to
| avoid the constant stream of attention and keep sane. I wonder
| what measures could be taken by celebrity OSS projects.
| JelteF wrote:
| Personally as an open source maintainer I like the typo/wording
| fixes/automated refactor PRs the most. There's almost no effort
| needed from my side to review them, so I almost always merge
| those very quickly. It's the PRs that implement huge are the
| ones that you take the most time reviewing/discussing, and thus
| those are the ones I put off looking closely at.
| EdwardDiego wrote:
| > Switching from using var to let.
|
| One particular GH user submitted multiple PRs doing only that.
| Across multiple JS projects...
|
| ...feels like GH profile padding.
| fmajid wrote:
| Not so much padding the profile as making the github
| contribution graph more solidly green.
| Null-Set wrote:
| There was a trend for a while for people to open trivial PRs
| against popular projects, I believe in an attempt to pad their
| resumes.
| gochi wrote:
| They can keep padding their resume if it means little fixes
| actually happen. Even typos and little translations, they
| affect the general reputability of the software. Sounds like
| a fair trade, especially as most hiring companies can just
| look at PRs and see what was actually changed very easily.
| kynetic wrote:
| This is still a trend unfortunately.
| erik_seaberg wrote:
| As jwz put it
|
| > This is, I think, the most common way for my bug reports to
| open source software projects to ever become closed. I report
| bugs; they go unread for a year, sometimes two; and then
| (surprise!) that module is rewritten from scratch--and the new
| maintainer can't be bothered to check whether his new version has
| actually solved any of the known problems that existed in the
| previous version.
| hackermatic wrote:
| It's like that with security findings, too.
| bluefirebrand wrote:
| Lodash is a great library. It's something I wind up using a
| little bit of on almost every project I work on.
|
| However, as JavaScript has become better and better, I use Lodash
| less and less. Every time I catch myself using it, I make sure to
| go see if there's a built-in for what I'm trying to do. I also
| find myself commenting on PRs with links to "you don't need
| Lodash for this" quite often.
|
| I still hope this isn't a sign they are stepping away from the
| project.
| darepublic wrote:
| It's definitely convenient but I think invariably I would
| prefer to just roll my own versions of its utils if it came
| down to it
| BoiledCabbage wrote:
| Why?
| kakadoodle wrote:
| Maybe start explaining why not, and then ask why someone
| would? I think it would create a more interesting
| conversation.
| 0000000000100 wrote:
| Less dependencies makes maintaining the project easier.
| SkyPuncher wrote:
| How? That's more internal code with bugs.
| sebastianz wrote:
| Some internal code with bugs is way better than lots of
| external code with other people's bugs.
| erik_seaberg wrote:
| Popular libraries have been battle tested in prod, and my
| teammates probably have prior experience with them.
| darepublic wrote:
| There are more than a few popular js libs that are pretty
| trash IMO. Though I would not count lodash among them.
| Battle tested can often just mean teams use them for
| better or worse, and I can often see in the code how bad
| frameworks cause juniors to contort their solutions in
| all the wrong ways to make them adhere to a framework
| instead of untie the knot and do it the right way.
| Sometimes it is the framework being used incorrectly. The
| devs should invest time to learn the API better. But
| often it's better to just learn how to do the solution
| sans framework rather than add to the stack of bespoke
| APIs to learn. And junior devs can become dependent on
| frameworks for every little thing to the point where they
| will always reach for one even if the choices are poor
| darepublic wrote:
| Because the surface area of lodash is so large and I need
| just a small fraction of it. And when I do need it it's
| easy to make a simple transparent version of the needed
| until rather than invoke a mystical black box. I admit this
| is opinionated and I have managed to work with lodash and
| keep my mouth shut about it
| BoiledCabbage wrote:
| Thanks for sharing - I disagree with the approach, but
| understand it.
|
| Or rather, I feel that can work for individual coding, or
| possibly very small teams - but in the end I feel it
| usually works out to be unintentionally anti-team
| behavior.
|
| It trades off "I need to learn and understand this black
| box of behavior for instead I have this code that I know
| and can easily reason about". While for the entire rest
| of your team it went from "there is this common pattern
| that most of all 20 (or however many) of us know - and
| instead makes it 19 of us now need to learn this non-
| standard behavior/implementation, but at least one person
| knows well."
|
| Essentially everyone else has to learn more code, so that
| one person doesn't. Agreed it's usually not the most
| complex of code, but it's usually buggier and shifts to
| cost / burden to everyone else. The opposite of economies
| of scale and leveraging prior fixed costs of learning.
|
| But again, I don't know your situation and will readily
| admit my opinion above doesn't in anyway make it
| factually a better approach. Just my opinion on it same
| as yours.
___________________________________________________________________
(page generated 2023-09-16 23:00 UTC)