5 ms·

> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s. Why would you possibly not? Increa

> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s. Why would you possibly not? Increased correctness, no change in runtime behavior, and a resistance to code rot and mistakes on your next concrete change. Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork.

virtue3 7y ago
> Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork. It's a bit disingenuous that you can accuse someone of being absurd for not doing something, and then mentioning in the same breath that you "might not want to" as well. I'm merely saying that for the sake of pointing out that maintaining a project is a PITA and we should all really accept that.
- eropple 7y ago
  It's not disingenuous; I have a number of open source projects on my plate already. I probably can't take on more. But if somebody hands me, for one of my projects, a set of typings that compiles clean in TypeScript (and, seeing as how it's a compiler, that's a really trivial thing)? I'd be literally-not-figuratively out of my mind to not say "thank you" and take them. Failure for another maintainer to do so means that they are a business risk for me that I should not entertain.
flatline 7y ago
> no change in runtime behavior That's the problem: how does the maintainer guarantee this? And when flooded with multiple such PRs, the task rapidly becomes overwhelming. If you have a robust suite of unit tests and a CI system you have better guarantees but still about as much work to ensure the new functionality is properly tested. That's not to say the maintainer's attitude in this case was excusable, but it's his project and this style of maintenance is definitely not for the feint of heart.
- eropple 7y ago
  In many cases, you're right. But here, specifically? If somebody goes through your code and annotates it with types, TypeScript is gonna scream if it doesn't build clean and is going to emit the same code it did in the first place. This is literally complaining that somebody might write helpful documentation for your system and that you'd refuse to merge it. It's a pathologically bad statement.

virtue3 7y ago

> Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork. It's a bit disingenuous that you can accuse someone of being absurd for not doing something, and then mentioning in the same breath that you "might not want to" as well. I'm merely saying that for the sake of pointing out that maintaining a project is a PITA and we should all really accept that.

eropple 7y ago
It's not disingenuous; I have a number of open source projects on my plate already. I probably can't take on more. But if somebody hands me, for one of my projects, a set of typings that compiles clean in TypeScript (and, seeing as how it's a compiler, that's a really trivial thing)? I'd be literally-not-figuratively out of my mind to not say "thank you" and take them. Failure for another maintainer to do so means that they are a business risk for me that I should not entertain.

flatline 7y ago

> no change in runtime behavior That's the problem: how does the maintainer guarantee this? And when flooded with multiple such PRs, the task rapidly becomes overwhelming. If you have a robust suite of unit tests and a CI system you have better guarantees but still about as much work to ensure the new functionality is properly tested. That's not to say the maintainer's attitude in this case was excusable, but it's his project and this style of maintenance is definitely not for the feint of heart.

eropple 7y ago
In many cases, you're right. But here, specifically? If somebody goes through your code and annotates it with types, TypeScript is gonna scream if it doesn't build clean and is going to emit the same code it did in the first place. This is literally complaining that somebody might write helpful documentation for your system and that you'd refuse to merge it. It's a pathologically bad statement.