Responding to "ttsc" (fork)

[nonara]

I have recently learned about a port of this library that uses the same name (ttsc) whose goal seems to be to replace this library.

The author of another library typia has announced he will be maintaining it going forward. This was in response to my taking longer than he'd like to support the latest TS v6, so I address this and more here.

I should say, it is awkward to be writing this to the public, but because @samchon has made a public announcement, it's best to write up my response to him here and also to express to the potential users who may migrate what the risk is.

I have not reviewed the library in detail, but I have experience with its author, and this is therefore relevant.

To start, although I aim for within 2 weeks max to support new TS, I cannot always do that. I regret that it took longer on this one, but I run 3 businesses and because of a client skipping out on a massive bill, everything I had was effectively set on fire. I'm fighting a clock trying to pull the impossible just to keep a roof over my head.

With that said, I will now address what I wish was handled privately.

To Jeongho, I don't want to offend you, and I appreciate the donations you've made previously.

I also respect your work with typia and the skill it takes to maintain it.

With that said, when you effectively announce "I'm taking over", despite having said days ago you'd wait another 2 weeks (Note: I am now working on v6 integration in ts-patch), you've now put me in the position of having to publicly respond to you in a way that's going to be uncomfortable for us both.

Here's why I have to do that. I carry the responsibility of being maintainer on multiple major supply-chain libraries. Collectively, they're downloaded 25M times per month and used in production in systems like GitHub and the top tech companies in the world. GitHub is also a financial sponsor. I've supported and maintained ts-patch for years, having had to take over for the prior author when the work became too difficult and he didn't have time.

I submitted patches and PRs to ttypescript for a while, until eventually asking if he'd like to deprecate, to which he graciously agreed.

This is a responsibility I don't take lightly. As a maintainer of a large library as well, I know you have some understanding of this.

The reality is, I'd love for someone to come on board to help in maintaining this. I'd even understand if someone ultimately rewrote it in a way that was better and committed to maintaining that more actively. I may not love it, but I'd ultimately be glad to know that the community was in good hands, and I'd be relieved to have one less thing on my plate.

So the issue isn't competition. I'll be straight. The issue I have is with you, specifically, trying to take this on.

Over the last three or so years, you've offered to help on this, but every attempt you've made has failed to actually be useful. Not only was it not useful, but you failed to be able to understand the code I wrote, much less the TS compiler code that we're modifying. Maintaining this well requires understanding Compiler Theory, Reverse Engineering, and the like. I have plans to handle the go version in the future as well, which may involve patching an actual binary.

Maintaining this in the go era is likely to be much more difficult work. In my view, what we've done so far isn't very difficult, but it has proven to be so for those who've taken an interest in helping, including you. I do always appreciate the enthusiasm and desire to help, but if you've noticed you've not been able to do the fixes for a single new release, it's surprising to me that you think that you can handle taking it over, especially in the future with a bytecode binary.

Years ago, when I first read your bio, my eyebrows rose in surprise — "The best programmer in Korea".

I said nothing at the time and have been kind to you, but since we're now in the uncomfortable position of my having to respond publicly to your bid to replace the library, I will say this: the fact that you'd label yourself as the best in your nation signals that your estimation of your own skill is disproportionate to the evidence.

That being said, I will reiterate: I respect your work with typia and the skill it takes to maintain it.

But, in past PRs your work was non-functional, unusable, and entirely misunderstood the problem we needed to solve. I had to discard most of the work and start from scratch. In your recent PR, you admitted it was done with Claude Code, and it "[Works] on my local machine ... but it fails for GitHub Actions ... I am not sure how to resolve this."

You say I let your PR sit in the queue, which is true, but I would not have done that if you submitted things that work.

I use Claude Code for many things. This is one of the few projects I will not do that for, because it's difficult work that requires every line crafted correctly, considering all possible edge cases.

My expectation for this is that I will be doing what I've always done, reviewing the TS compiler codebase and the compiled binary, and determining the holistic approach to work uniformly for all versions, as I always have.

I should also note that this isn't meant to shame anyone for not being adept in a specialized niche. Many great programmers go their entire careers without needing to work in compiler internals.

So what's the issue…

If someone capable takes my work, forks it, and maintains a better version, I may not like it, but I won't fight against it. As I said, it would even be a relief. But, if someone who I know doesn't have the skill to do it tries to and manages to pull users away, it creates a serious liability for the users I've worked hard to serve for years.

Not understanding this code means potentially introducing bugs or security issues for compiler-level code, which is a key part of the build process for countless projects, both in leading enterprises and small operations alike.

I cannot in good conscience stay silent if I know someone is attempting to siphon users away to something whose most capable mind is Claude, when I wouldn't even trust Claude on this myself.

So, as I said on X, fork if you must, but so long as the project remains, my objection will.

On my part, I am working hard to find a way to consolidate and schedule in my OSS responsibilities so it does not take as long for updates for new versions.

Critical security issues, I'm quick on, but things like supporting new TS can sometimes take a while, which is understandable, yet I'll try to do better.

And, if someone can do the work, I'd love the help.

• @nonara

Jeongho: I'd be happy to take this note down if you want to discuss privately. You can DM me on twitter. If you do wish to keep trying to maintain a replacement library without someone suitable to work on it, I'll likely still take this down and post a broader blog post about it linked from my readme that links to the alternative library and details why there's a risk.