There is some interesting [drama][1] with this, since this article noticeably doesn't mention any PRs they opened to remove some of these older polyfills.
The reason those PRs were never opened/merged is the maintainer of many of those libraries [has a strong stance on "breaking" changes][2] in software:
> I have developed an intense avoidance for breaking changes in all of my packages, because I don't want to inflict hundreds of millions of dollars of person-hour cost on the entire industry unnecessarily.
IMO this argument avoids the opposite claim, that people then spend a ton of time (and money) trying to make old tech work with newer tech since not everyone maintains to the same standards of backwards compatibility.
But regardless, no one is required to stick to a particular way of creating open source software, so the one benefit here is that you are free to [fork the library][3] (assuming its license allows for that) to remove some backwards compatibility that isn't relevant to you.
Nothing moved for a while, and I think he said something along the lines of “if you want React 17 support, stop complaining and help”. So the community got involved. There are multiple PRs adding React 17 support. Many unofficial React 17 adapters. A lot of people have put a lot of work into this, ensuring compatibility, coverage etc. Yet to this day, none of them have been merged. Eg https://github.com/enzymejs/enzyme/pull/2564
Given the amount of time that has passed, and the work the community has put in, something is amiss. It feels like he’s now intentionally avoiding React 17+ support. But why? I don’t understand why someone would ask for help then ignore the help when it comes in. That isn’t much better than the swathe of rude/entitled comments he was getting on the issue before he locked it.
I ended up migrating to RTL, but this made many of my tests more complicated (especially compared to shallow rendering).
I'd guess the issue with that project is that it is mostly a single person effort and if that person is busy with other projects/repos/real life, they might not have the bandwidth to keep-up with the review, loose interest or maybe did not notice the PR update in the stream of incoming requests.
I guess the community (if there is any) can request to have more maintainers added to the repository to share the burden, else you still have the option to fork the repo and publish it under a different name.
I get being busy. But it’s been three years, and he keeps saying the project isn’t dead, so he hasn’t lost interest. Also, he asked for help then largely ignored the help and/or started bike shedding the PRs. He’s 100% across everything that happens in the repo, investing a lot of time replying to every comment immediately.
I’m pretty sure people offered to become maintainers and he declined. Forking has its own set of problems, but yeah you’re right, this is at least a possibility.
He's frequently on a powertrip and confidently wrong about so many things. For instance he's one of the people who perpetuate the "Javascript is fast and you don't need to optimize anything" falsehood. No wonder he's bringing in 100 polyfills into everyone's project. He thinks JS is C.
I am _appreciative_ that people like him exist, because -- personal feelings aside -- we do need people who have his level of dedication in the open source space.
My only interactions with ljharb have been in TC39. More often than not when looking at issues he's active in, I find myself wanting a level of maturity and thoughtfulness that just isn't there.
His contributions are neither novel or very compelling. He's more of an open-source bureaucrat than an engineer or a developer, yet he is currently steering several major TC39 proposals. I've seen him shutdown or sidetrack valid input and criticisms in all of them. The vibes I get from his behavior are akin to him being a member of "the cool kid club" -- wanting to maintain that ingroup/outgroup boundary very tightly.
He really should just get out of the standards/committee space entirely for the time being, and get some coaching on leadership skills before reentering. I realize this is super negative. Still on the ropes whether or not this feedback belongs in the public space.
Insanity. In projects where I have full technical control I don’t use eslint anyway, it creates a massive load of work for negligible (if any) gain. Typescript finds the important issues, prettier fixes formatting; linters just create giant swathes of useless busywork.
I think your description of linting can be true, but not necessarily for every eslint configuration. I feel that I've landed on configs that feel useful to myself and the rest of the devs in the team. Even with a rule set that contains many rules that can look nit picky at first glance, no one complains since they are auto fixable, and fixing is a part of a commit hook.
There are a handful of rules that are nice to have in a TypeScript project to make sure devs don't do things that break type safety. Plus some that avoids mistakes from slipping through (even though the code is reviewed).
One thing I've found super useful is to have @typescript-eslint/ban-ts-comment enabled, but configured so that you can still use @ts-expect-error and the others as long as you provide a comment when doing so. This is so nice when doing code reviews, either someone has provided a very good reason for the exception, or it is clear that the same result could have been achieved with a better approach. Same goes for disabling eslint rules inline in a file, also allowed if commented. I feel that this is a very good compromise between being strict with linting, but also not letting linting get in the way.
Yeah there is like one rule that I often try to fix, the “no non-null assertions” rule (some.property!), because it often leads to bugs. I kind of wish you could just disable non-null assertions at the compiler level really. Maybe strict mode should do that.
I can’t think of any other lint rules I find valuable. For the giant mass of node_modules you need to run eslint, I think its cost-benefit is pretty darn terrible.
I’ve done that, and I’ve coded on projects with big teams, with and without linters, for way longer than that, with multiple languages. Linters have never contributed anything close to what a half decent type system does to a project.
Types, tests, lints are all complementary. Your comparison is meaningless. The fact that you'd even compare the two shows how much your experience with linters is worth.
"I don't wear a helmet because I can just drive slowly"
"I can eat this 8-patty burger because I'm going for a run later"
You know, it's heresy to say, but if there was some kind of analytics or reporting done by the plugin we could know for sure that no node v4 users are out there on it and upgrade the deps and be done with the whole argument.
> But regardless, no one is required to stick to a particular way of creating open source software, so the one benefit here is that you are free to fork the library (assuming its license allows for that) to remove some backwards compatibility that isn't relevant to you.
I think that's the most important takeaway here. The library author decided not to make breaking changes and to keep compatibility wherever he can. I don't think that's a requirement many people have (not to this level, anyway), but it's not unreasonable either.
No project is required to use or accept his code. People want qs, resolve, and nvm.sh, and this one person is willing to provide it to everyone for free.
I don't care if he refuses suggestions because of "breaking changes" or because "they don't spark joy". It's his project, you can disagree with him all you want, but you can't complain that the free work he's doing isn't to your liking.
I think it's telling that a lot of people are willing to argue with the maintainer but very few people are willing to step up to provide and maintain a better fork.
Is there not a config for minimum supported JS version? That would appease everyone, while maintaining backwards compatibility.
Docs should show the recommended version (modern) and show what options are available to go deeper.
Obviously adding those settings for every pollyfill in non-trivial, but burdening everyone with every pollyfill ever is also suboptimal. If anything, this would make cleanup easier going forward since it would all be classified
There is an "engine"!entry in package.json, and a package manager should be smart enough to not upgrade past what it can. But people tend to not use that sort of dependency flexibility and use lock files…
The reason those PRs were never opened/merged is the maintainer of many of those libraries [has a strong stance on "breaking" changes][2] in software:
> I have developed an intense avoidance for breaking changes in all of my packages, because I don't want to inflict hundreds of millions of dollars of person-hour cost on the entire industry unnecessarily.
IMO this argument avoids the opposite claim, that people then spend a ton of time (and money) trying to make old tech work with newer tech since not everyone maintains to the same standards of backwards compatibility.
But regardless, no one is required to stick to a particular way of creating open source software, so the one benefit here is that you are free to [fork the library][3] (assuming its license allows for that) to remove some backwards compatibility that isn't relevant to you.
[1]: https://twitter.com/ljharb/status/1704912065486618915
[2]: https://github.com/import-js/eslint-plugin-import/pull/2447#...
[3]: https://www.npmjs.com/package/react-outside-click-handler-li...