Future of TypeORM

[pleerock]

We are working full-time on TypeORM for almost three years. That’s why we have such a powerful and really amazing ORM. And this time wasn't funded or sponsored by anybody except our core developers - (@pleerock and @AlexMesser). And three years is a huge amount of time and it cost us lot of resources.

---

Open source is free, but if you want a really high-quality open source with a good support, code reviews, new features, performance and bug fixes - our core developers should spend much more time on it. And we all know that time is money. TypeORM is a huge and very complex library. Ideally it requires a few full-time paid developers. Nobody is working full-time for free, you should understand that people have families, kids and they have to live on something. They simply can't be unemployment and work on TypeORM full-time.

---

Again, being a full-time is very important for this project because developing a good orm is a very complex task as it takes a lot of time to maintain it, develop a new features, review pull requests, answer people questions, maintain all this infrastructure. Without being a full-time we loose in all those areas and processes are very slow.

To understand scales, I'll provide you an example. In last few months I've got 1000+ github notifications from TypeORM repository. They include github issues and pull requests. Now imagine how much time it requires to:

• read each issue
• review its code
• clone attached repository and test it (if it was attached)
• try to reproduce issue and understand the problem
• close issue if reproduced issue was just a user mistake (most of cases) or fix it if its a bug
• or review a pull request and discuss each change people do

Of course there are lot duplicates, lot of just comments, etc. but even if we take an average of 10 minutes per issue (including most of steps above, except actually fixing the bug/feature request) then it becomes almost a month of full-time work! Just to answer people questions and requests. Now imagine during this month lot of new issues created and this process never ends!

Now let's think what TypeORM actually needs:

• new cool features
• performance improvements
• support latest ES and TypeScript features
• improve developer productivity

Now imagine if its possible to do first and second without being full time.

---

If you love TypeORM, enjoy using it, if you want to thank authors, if you want it to evolve extremely well and donation doesn’t really cost you anything, please donate. Any amount you can do monthly or you think TypeORM deserves.

From our side we are going to provide you a high quality support:

• For those who donate as Sponsor you can ask questions directly to our core contributors in slack (or any other way) and you are guaranteed to get your answers
• For those who donate as Gold Sponsor you can ask questions directly to us, ask for feature requests, bug fixes, etc. and they will be resolved in a priority order. Also, we can make a calls and discuss certain TypeORM related issues or design decisions in your projects.

Use our open collective page to donate.
Thank you for understanding and your support!

[havenchyk]

@pleerock please create a tweet about this and ask for retweet at least. Also it makes sense to wrap this huge text into a medium post

[ematipico]

I just want to add that this Open Source project is maybe one of the best open source projects I have ever seen around. You guys are doing a really amazing job!!!

[pleerock]

@ematipico thank you!

[Bessonov]

I totally agree and understand you! May be you should:

1. Place this description and sponsors at beginning of README, not end.
2. Instead of just "Sponsors" section, ask for action to become a sponsor.
3. Place short description of your challenges and link to open collective in the issue template. Ask for high quality reports.
4. What's about tweet and other posts in social media, as asked by @havenchyk? We want to share it.

EDIT: found the tweet: https://twitter.com/typeormjs/status/1074728123554586624

[AnthoniG]

Why not use Open Collective https://opencollective.com/
I use that site to give money to Dokku.

Just a thought 😄

[pleerock]

@AnthoniG we are using OpenCollective

[rustamwin]

@pleerock what about Patreon

[pleerock]

@rustamwin what is the point of using two donation systems? I guess donator doesn't care about where to donate?

[rustamwin]

Some donators maybe use Patreon

[pleerock]

@rustamwin for me two donation system just confuses thing and for me it looks like people won't know what system to use for donation. I'll create a Patreon if any donator ask for it.

[zuohuadong]

Place this description and sponsors at beginning of README, not end.

If we can get the investment, we will donate to typeorm soon, thanks to the contribution of typeorm.

[consense]

broke the 10k milestone :-)

[dcworldwide]

Donated. Thank you. A donation is a small price to pay for an excellent library that has saved me hundreds of hours.

[trixden]

Dear developers. I want to say that the problem can not be only on one side.

I could write my projects using your ORM, and give a part of my earnings to you. So I always did, that's the way it should be.

But if I am writing a project for production, this means that I can not find time to contribute to your ORM. I need a stable solution to write a project on time, and do not exceed the deadline.

That moment came recently. As technologies for the new project, I chose Nest.js and of course, TypeOrm. I recently found a trivial issue that I reported to you. You have not answered the fourth day. Let me remind you, I have a deadline. What should I do at such moments? Right. Search alternatives.

Please do not think that I am angry with you. I'm just trying to explain to you how things are on the part of the developers. I guess you think that everyone is using your development, and no one wants to share money with you. It is not always so. I could, but I had to find another solution.

We do not work full time because people do not donate us. People don’t donate us because we don’t work full time. It's a vicious circle. Someone has to break out of it. And in opensource projects it should always be a developer. Because he initially understood that opensource is deferred earnings. First he does, then he earns. So, can you first close 600+ issues, and then talk about donations? ;)

I very much hope that you will not take my message as a simple flash of aggression and extract from it a useful idea for yourself. In the meantime, I will again write a project on Django. I really hope that I will write the next project using your ORM. Good luck :)

[pleerock]

So, can you first close 600+ issues, and then talk about donations? ;)

@trixden its not a reasonable request. We already have 2400 issues closed, and it took HUGE amount of time, years of full time work. Do you think many people whom I already helped started to donate? When people's issues are resolved they simply disappear, nobody cares about doing something else. Nobody understands how much time and efforts it took for developers. Nobody appreciate exist job that already have been done. You already have a great product, that deserves many, and you are asking about even more not doing anything for what you already have. I have spend over 100k of my own resources to bring what you already have right now. Did you think about it before using it for free? Don't you think to give something for what you already have? Closing 600+ issues will take another year to resolve if I work full time on TypeORM, are you suggesting me to quit job and start working on them? Of course I can't afford it myself. The only solution is to ask people for donation, wait when enough people do it, then start doing the job. I understand you are a new user and face problems like this, but what you are asking doesn't make sense. There are other people who appreciate exist efforts that they already have for free and are interested to help to make it even better and this ticket opened for them, not for people who are used to use other efforts for free and never return something back.

[trixden]

@pleerock i realy understand you, and it's very sad. Yes, If there are many projects in production written with TypeORM, and developers donated nothing, this is very bad. I understand that behind this free project there are long works of developers. If I had written at least one project in production using TypeORM, believe me, I would have done so that I was not ashamed of the questions you asked above. But now i can't do that.

[Bessonov]

Strongly disagree with @trixden . It's not how open source works. Open source is about sharing. @pleerock already made the first move and spend enough time to create this great product, which can compete with more mature alternatives. So, what did you done for TypeORM, @trixden? Create an issue report? Great! But why should anybody care about it in the free time? @pleerock care about that. But wait, why don't you contribute to TypeORM and create a high quality pull request to fix your issue? Why don't you want spend your free time, like @pleerock already did? Do you feel open source spirit?

[Ginden]

BTW, tsconfig.json for TypeORM specifies "target": "es5". Node 8 supports es2017 and I think this should be default.

Browser users have to transpile their code anyway.

For Node users it would likely enable async stacktraces.

[imnotjames]

BTW, tsconfig.json for TypeORM specifies "target": "es5". Node 8 supports es2017 and I think this should be default.

Browser users have to transpile their code anyway.

For Node users it would likely enable async stacktraces.

We really only test for node 12+.

Might be safe going to es2019

I've opened #7967 to see how tests fare.

[ghost]

Im unsure, I understand the donation goal (for the good work that's done here) etc. but currently the donations are at 1k/month (9k away from goal). Does this mean the repo is currently "dead", and the new version 0.3.0 with addSelectAndMap() will not be released soon?

[christian-forgacs]

Any news when this project will continue in development? There are many good open pull requests without issues and unresolved reported issues.

In my opinion if the project owners doesn't have enough time for this project, they should look for active contributors who have the time and the intention to participate in order to process pull requests and to develop directly into it.

Of course there is a lot of heart and soul in this project from the creators, but when the project is too big it needs more than a few people to maintain. And I think the community is big and good enough to support the project. Best example for it is Vue.js. The complete project is initialized by one people and he add in the meantime over 50 maintainer.

I think if you add only a few more maintainer this project will become much more pace.

[aboveyunhai]

Any news when this project will continue in development? There are many good open pull requests without issues and unresolved reported issues.

In my opinion if the project owners doesn't have enough time for this project, they should look for active contributors who have the time and the intention to participate in order to process pull requests and to develop directly into it.

Of course there is a lot of heart and soul in this project from the creators, but when the project is too big it needs more than a few people to maintain. And I think the community is big and good enough to support the project. Best example for it is Vue.js. The complete project is initialized by one people and he add in the meantime over 50 maintainer.

I think if you add only a few more maintainer this project will become much more pace.

The project is always in development. The latest release is 2m ago, which it's not too bad upon its current complexity.

There are many issues and PR are leave as it is because the maintainers decided not to close anything stale by bot. If you ever noticed that in many huge libs, tons of unsolved issues are auto closed, hence people need to review voluntarily it one by one. (I usually don't judge libs if there are lot of issues, check the content first, many might be just their own mistakes instead of bugs)

The problem of PR and issues are that most of them are not easy questions, people have passion but don't have the ability to solve it. And remember it's an ORM, a trouble PR or fix can cause huge data corruption issues without concerns.

Ultimately it comes down to the budget, the current budget is not able to incentivize enough people to help maintain it daily. Vue has huge budget by contrast.

[christian-forgacs]

The project is always in development. The latest release is 2m ago, which it's not too bad upon its current complexity.

There are many issues and PR are leave as it is because the maintainers decided not to close anything stale by bot. If you ever noticed that in many huge libs, tons of unsolved issues are auto closed, hence people need to review voluntarily it one by one. (I usually don't judge libs if there are lot of issues, check the content first, many might be just their own mistakes instead of bugs)

The problem of PR and issues are that most of them are not easy questions, people have passion but don't have the ability to solve it. And remember it's an ORM, a trouble PR or fix can cause huge data corruption issues without concerns.

Ultimately it comes down to the budget, the current budget is not able to incentivize enough people to help maintain it daily. Vue has huge budget by contrast.

@aboveyunhai its correct that this project has a judge impact if PR or fixes go wrong. But other ORM projects has this project too.

My compare with Vue is rather from the beginning and not from now but yes I know what you mean.

But I'm not the only one in this discussion who thinks this project is a little bit on hold. If it's not as you say, show the community more signs of life for example search more people how contribute for free in the main team. Currently this project has 750 contributors but I'm don't know how many maintainer can review PR.

Don't get me wrong. I like this project and use it in projects. Also I add a little PR in the last month. I'm just looking for solutions <3

It's a big challenge to realize a project like this. Overall big respect for it.

[jbjhjm]

@christian-forgacs I had some small pull requests being merged over the last few months.
Pleerocks focuses on the new major version, so I don't expect he's going to merge huge new features that might break stuff (even tho they could be very useful). He knows best how error prone and complex some parts of the code are.
So I can understand the decision that this is not the time to stuff new features into the old version, as that would easily end up with him managing issues and handling bugs.
Of course it would be awesome in general to have more "core" devs that are allowed to handle PRs.
But afaik due to the monolithical code base they'd need to be extremely experienced with all code to be at one level with pleerock. Maybe will happen with the future more modular approach. It is not perfect, but it is what we have right now. I can respect and accept that.

[MattEagle95]

I think it's dead. Everyone talking about new PRs and stuff being merged, but it's dead for years now, just living because of nestjs. There are breaking bugs (selectAndMap, raw mapping of subqueries in joins, relational loading strategy etc.), merge ready, but forgotten PR's, which make it impossible for new business apps to adapt and use it.

[Ginden]

@pleerock @AlexMesser I once again reiterate my willingness to be a triage.

[jrista]

@MattEagle95 I don't think thats really fair. There has been activity recently, most recently 9 days ago on Jan 15th, but numerous commits were made throughout Dec. as well. I think there are some major issues that need to be resolved, and I think the project owner needs to seriously consider the offers some people (from an interested community...this project definitely has interest and that is important) to help manage and maintain the project over the long term.

I do think some of the more critical issues need to be addressed in the short term, rather than waiting for a complete rewrite of the framework to be completed. Even if that does not happen though, I don't think the project should be considered dead. Once a new version does finally hit the streets, especially if it resolves the major issues right in the core of the library, that should give it a solid revival.

[Ginden]

I do think some of the more critical issues need to be addressed in the short term, rather than waiting for a complete rewrite of the framework to be completed.

Personally I think that idea of "make lots of breaking changes in single version" is fundamentally flawed - people will remain stuck at older version, because migration cost is too high.

[jrista]

@Ginden Yeah, there is definitely that risk of alienation. If the changes are that extensive, that gets back to one of my prior comments that, maybe there needs to be a new repo, and a new TypeORM 2 or something, to make the break more definitive. I think it is tough to deal with a major foundational refactor in the same repo and continuation of package versions. A clean break with a new repo and new package name makes it clearer that there ARE foundational changes.

The older version could then continue to be maintained and refined, without massive breaking changes.

[Ginden]

Some breaking changes are obviously required - but these should happen gradually over longer time.

[jbjhjm]

@Ginden IMO it depends on how good migration can be prepared and differences are documented.
If it's no poking around in the dark, I'd prefer to do it all at once than having to alter code due to breaking changes every few weeks.

[Ginden]

Minor: it may be reasonable to drop Node 13 tests from CircleCI and replace them with Node 16.

[productdevbook]

I will update and send a pr to do the documentation in 2-3 months. I think please close this place and do pr work for the sponsor. Use Twitter actively.

I think you need to attract people so they can become sponsors.

https://twitter.com/typeormjs

[zetti-caletti]

@nebkat I sometimes also have trouble with Typeorm. I am willing to contribute to this, but PR aren't merged.
What is stopping us from forking the project and keep that fork more or less maintained? We just need to find some maintainers (me included). What are the legal things to keep in mind to fork the project?

[alexey-sh]

We are working full-time on TypeORM for almost three years.

@pleerock Умед, бародар, а на что ты живешь, если фултаймом занимаешься этой либой? Рахмат

[jmpreston]

@pleerock Are you working on the new code for TypeORM? Are you happy with the progress?

[pleerock]

@jmpreston nope, as I received many negative comments, the work on a new code was stopped, and instead some of the ideas from the new version were implemented and merged into 0.3.0 a while ago.

[pietroLondero]

@pleerock sorry for the question
so TypeORM is now on maintenance mode and won't get any big update in the foreseeable future?

[pleerock]

@pietroLondero TypeORM is mostly community-lead project. Community continues to contribute different features, and me and @AlexMesser always tend to review and merge them. So, if you talk about "big updates" from the community - TypeORM will continue to receive them. If you talk about "big updates" as "big breaking changes" - we avoid bringing them, because most people negatively accept them.

[michaelbromley]

Hi @pleerock & @AlexMesser

I love TypeORM & it is a major part of our stack at @vendure-ecommerce. The updates with v0.3.0 were very welcome.

I'd like to bring up the subject of ongoing maintenance, since your last comment in May. The last TypeORM release was v0.3.17 in June - 6 months ago at this time of writing. In the mean time there have been some commits but no releases. One commit in particular (#10004) resolves an issue that has prevented us from updating to any newer version than 0.3.11.

But the broader point here is that the huge TypeORM community (including me, and all of our many users) has a strong interest in seeing if there is something that can be changed so that TypeORM maintenance gets back on track.

In this message I in no way want to place any blame or accusation at anyone involved with TypeORM. This library is a gift and the unimaginable work done so far has benefitted all of use greatly. I also understand the burdens of OSS maintenance very well.

With that said, I would like to explore how we can reach a point where:

• Current fixes already merged can be regularly released
• Open PRs that have a low review overhead (clear fixes with tests, well-documented etc) can be merged

At this point I'm not even asking for major innovations or updates to the APIs. Just day-to-day housekeeping really.

My suggestion would be to delegate responsibilities (PR review & merging, releases) to trusted community members. What's "trusted"? Well, we'd have to figure that out, but e.g. devs from large companies heavily invested in TypeORM, devs with track records of good PRs & issue triage, etc. I would be happy to get involved here - I've already contributed in the past to TypeORM and I am definitely interested in its continued success.

Thanks for reading and I'd really be interested to hear your ideas on how you see TypeORM's future as we head into 2024.

[giosueDelgado]

Hello everyone.
I completely agree with what @michaelbromley said.
We have used typeorm for a new platform and at the moment we have several technicians who are skeptical about continuing to use it for a few updates and a few fixes, we also think this could be solved as @michaelbromley says by greater organization in the community given that many people are interested to this.
We are also available to support if necessary.
In a totally transparent way given the alternatives to typeorm (prisma, mikroorm, etc.) if typeorm wants to remain a main choice it must recover the ground lost in recent months when the others are growing significantly in terms of support, feature, ecc..