Seeking sponsorship to restart development

I'm looking for companies or individuals who benefit from ts-node and would like to see continued updates to sponsor work on this package. I'm more than happy to coordinate with featuring company logos on the README/website, or discuss other ways to show appreciation for sponsorship of work on this package.

It's been a while since this package has had a regular maintainer, and more than a few years since I was involved, but I know many people use this package and I would like to keep it maintained and up-to-date. However, the surface area has grown over the years and it's certainly not going to be a small effort to update it, keep it updated, and respond to all incoming issues and PRs. I would use the sponsorship funds to go full time on updating the package.

Some of the things I'd like to see done:

Rewrite to support the latest ESM loading APIs, remove all the hacks related to older node version support
Bump the minimum node.js supported version
Improve overall runtime performance and memory usage
Fix and update existing test suites
Simplify the supported API space so new maintainers can quickly onboard
Review and close the 200 open issues and PRs

If you are seeking an alternative to ts-node, I would recommend tsx.

Please keep comments on topic. Feel free to email me if you prefer.

@blakeembrey

@blakeembrey hi, I'm a bit confused. This project resides under TypeStrong namespace, as opposed to being under an individual's. This means it currently has at least 15 maintainers:

These are only those who opted in to being "public members", the actual number I presume is much higher (on Github for some reason group membership is hidden by default unless you turn on your visibility explicitly).

So why are you saying the project has no maintainers?

@blakeembrey

@blakeembrey hi, I'm a bit confused. This project resides under TypeStrong namespace, as opposed to being under an individual's. This means it currently has at least 15 maintainers:

These are only those who opted in to being "public members", the actual number I presume is much higher (on Github for some reason group membership is hidden by default unless you turn on your visibility explicitly).

So why are you saying the project has no maintainers?

The number of 'public members' of a github org doesn't say anything. These are people that have been added to the github org at some point in time.

Check the contributors of this repo to see who actually did the work here (to no surprise, it's mostly @blakeembrey and @cspotcode (edit)).

https://github.com/TypeStrong/ts-node/graphs/contributors

The number of 'public members' of a github org doesn't say anything. These are people that have been added to the github org at some point in time.

If you think these are random unrelated people, it's kinda misleading. For example, I can't just get into the group if I want to. These are certain people that are there for certain reason.

A Github group allows people to combine development efforts on a single project. When the group accepted ts-node to be one of their projects, that made all people in the group to be equally responsible for the project.

I see your point that these people didn't and don't contribute to the project, but this really just makes whole TypeStrong group questionable.

@Gerrit0

I'm wondering if we could get a comment from a group member. For example, I see @Gerrit0 has commits on a sibling project, CCing.

I'm wondering if we could get a comment from a group member. For example, I see @Gerrit0 has commits on a sibling project, CCing.

Instead of pinging random people that happen to be in the same org to do the work, how about you consider to sponsor the project, as requested by the OP?

I see your point that these people didn't and don't contribute to the project, but this really just makes whole TypeStrong group questionable.

Maybe it's good to adjust your understanding of 'organization'. It's not per definition a company that has these developers on their payroll. It's to 'organize' who has access to the repos under TypeStrong.

how about you consider to sponsor the project, as requested by the OP?

I don't have motivation, because I am completely new to the TypeScript ecosystem, and, like, problems with TS interactive repl was the first thing I stumbled upon. I fixed it (both locally and sent a PR), but I realize there's no one to accept the changes.

I did take maintainership over purescript-mode for Emacs some months ago while working on PS-based project; but taking over maintaining ts-node isn't currently on something I'm interested in. That said, I do have plans bringing up within my company if we could maintain ts-node, but… Idk how it's gonna go, I strongly suspect not very well.

This means it currently has at least 15 maintainers

No, it means it is in a group so that if a current maintainer got hit by a bus, someone would still have access to be able to let a project keep going without a fork if someone else wanted to maintain it. Despite being a member of TypeStrong, I don't have write access to this repository as I'm not a member of the internal ts-node team (that's just Blake and Andrew) and am not a TypeStrong admin.

The majority of the members of the TypeStrong organization are not involved anymore with any of the projects under it... I think I've only ever interacted with 5 others in the organization. For example, TypeDoc -- I am the only maintainer actively working on it. Anthony Ciccarello passed it off to me several years ago, after Sebastian Lenz passed it off to him a year or so before. If I stopped working on it, TypeDoc would be in exactly the state that ts-node is today -- effectively unmaintained.

Nobody is obligated to maintain an open source project—not even the initiators or current maintainers. They are free to work on it, so its upkeep depends entirely on the support of the community or other maintainers. It seems that no maintainer has enough motivation left to keep this library alive for free, which is understandable because everyone has their own life. However, the lessons learned from ts-node are as follows:

An open source project should inspire others to contribute as it grows so that the library doesn’t rely solely on the main contributors’ motivation. This also allows new contributors to join the project because there will always be someone to guide newcomers. The key point is that this library has only two contributors, despite having more than 30 million downloads per week.
Selecting an open source library as a dependency for your project requires experience. I never thought that a library which once reached 70 million downloads per week would collapse before I saw this example.

always a good read https://liberamanifesto.com/

If you think these are random unrelated people, it's kinda misleading.

I disagree. That list includes people who may or may not be active, or who have been active in the past. As one of the last remaining people trying to stay active in Rollup's org (it's really down to me and Lukas now), we keep the maintainers on the rolls in case they want to come back and contribute again. This is how Github has worked for many moons.

Putting a disclaimer and/or archiving the repo would be the least and easiest courtesy to the community and unsuspecting users.

Certainly a disclaimer in the README at the very top would be good as I wasn't aware this was unmaintained until I looked at npmtrends. It also doesn't seem that there is a group of potential sponsors forming?

Additionally, it looks like the requirement of tools like this is fading given Node are introducing native TypeScript running as a feature.

https://nodejs.org/en/learn/typescript/run-natively

nodePackages.ts-node: drop

I agree that adding a comment to the README would be appropriate, given that there don't appear to have been any commits to main or new releases in two years.

In the meantime, while tsx or Node's experimental built-in type stripping are good options for most usecases, there doesn't seem to be any good alternative to ts-node at the moment if you need typechecking or to emit legacy decorators. swc-node does not offer typechecking, although it may be a viable option for decorators (with some configuration.)

@blakeembrey

@blakeembrey @cspotcode Dear maintainers, people keep coming to this clearly abandoned project and hit their heads against the wall of issues, wasting time for literally no reason.

Would it hurt your CVs so much that you refuse to archive the repo or at least direct people to alternatives in some well visible place (like the top of the readme and the website)?

@blakeembrey

So then, is there anyone who is against the idea of merging a PR to update the README?

Is anyone still around who has the rights to do that? cc @blakeembrey @cspotcode

It also feels like we're in the territory of marking the npm package itself as deprecated...?

https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions

At least these would be fairly trivial changes, and would flag to developers to use something else.

feat(cli): run the TypeScript template with tsx instead of ts-node

feat(cli): move the TypeScript template to tsx and TypeScript 6 (#396)

Navigation Menu

Repository navigation

Seeking sponsorship to restart development #2140

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Seeking sponsorship to restart development #2140

Description

Activity

Hi-Angel commented on Apr 2, 2025

beeman commented on Apr 2, 2025

Hi-Angel commented on Apr 2, 2025

Hi-Angel commented on Apr 2, 2025

beeman commented on Apr 2, 2025

beeman commented on Apr 2, 2025

Hi-Angel commented on Apr 2, 2025

Gerrit0 commented on Apr 3, 2025

bakikucukcakiroglu commented on Apr 15, 2025

shellscape commented on May 15, 2025

KazimirPodolski commented on Jun 17, 2025

rubengmurray commented on Oct 10, 2025

ialexryan commented on Dec 6, 2025

KazimirPodolski commented on May 15, 2026

rubengmurray commented on Jun 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions