RFC: Fork TypeORM

[michaelbromley]

Background

TypeORM is the library we use in Vendure to interact with the database. It is a highly performant (comparing very favourably to Prisma and Drizzle in these benchmarks published by Prisma), is feature-rich, and mature. It currently has around 1.9 million weekly downloads on npm.

However, the library is currently effectively unmaintained. At this time of writing, it has had no commits for 7 months and no releases since January (9 months ago).

There are 2.4k open issues and 147 open PRs. Several of those PRs are fixing critical issues that are causing bugs in Vendure:

• Setting a relational customField on Asset with relation Asset results in Errors  #2891
• Big bug for vendure handle typeorm for custom fields with relation & eager:true #1873
• TypeORM foreign_key names #2542
• Defining eager: true on customField stops custom entity to load own eager relations #2687

In addition to that, there are now critical vulnerabilities being flagged up by code scanning tools are flagging up a high-impact vulnerability in the current version:

• Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') in TypeORM

All of this creates a number of problems for Vendure:

• Bugs which we cannot fix in our own code, and have no confidence will ever get addressed
• Potential users put off Vendure due to dependency on an unmaintained critical component
• Enterprise users doing due diligence alarmed by high-impact vulnerabilities in code scan reports

Options

Although TypeORM works well for us (the above bugs notwithstanding), the current situation is not sustainable. Therefore something must change. Here are the options we have considered:

Migrate to an alterative ORM

There are a number of other ORM solutions such as MikroORM, Prisma & Drizzle. In themselves they are all worthy options and if we were starting out from scratch they would all be viable options. However, considering our large userbase - many of which are enterprise companies with lots of custom code in the form of Vendure plugins, there are a couple of huge downsides to this option:

1. It will be a massive job to change out TypeORM from core. 673 uses of the this.connection, not to mention other TypeORM-specific features we use such as subscribers and custom decorators.
2. The same will be true for user code (on a smaller scale). But virtually every Vendure plugin will make use of the TypeORM APIs in some way.
3. Moving to a new library comes with its own set of unknowns. It is one thing to evaluate the APIs and do a proof-of-concept, but only after extended, real-world use do the true characteristics of performance, DX etc become apparent. TypeORM has the huge advantage here in that it is very well known and understood.

This option has a significant risk of creating a "python 2/3"-style split in the community, as existing, large-scale Vendure applications cannot justify the significant time investment in migrating, the plugin ecosystem becomes split, and existing knowledge and practices become obsolete. For this reason I am ruling out the option of migrating to a different ORM.

Wait for the TypeORM community to fix things

In a very long thread on The Future of TypeORM (where these issues are discussed at length), the situation of lack of maintenance has been a topic since way back in 2019.

More recently, a community member announced that they are working with the creator of TypeORM to address this situation by putting together a community-driven team of maintainers.

We had high hopes for this but unfortunately, since the announcement in July 2024, there has been no further communication on this effort. I have also personally reached out to the volunteer (who is also a member of the Vendure community) but cannot get any details of what, if anything, has been done on this.

Four months with no visible forward progress is too long and we are no longer confident that this effort will successfully resolve the TypeORM maintenance problems.

Fork it

This leaves us with the option of forking TypeORM and maintaining our own version. This is also not a decision to be taken lightly, which is why I am writing this RFC because it affects all Vendure users.

A fork would have the following goals:

1. Address urgent issues by getting fixes in to the library that are already languishing in unattended PRs
2. Resolve high-impact vulnerabilities
3. Simplify the project by removing core support for MongoDB, SAP HANA and potentially MS SQL & Oracle (to be evaluated)
4. Begin to clean up the code base to make it easier to maintain
5. Keep a regular release cadence, with fixes merged and released in a timely manner.

Non-goals:

1. Adding support for any other DB types
2. Changing the API
3. Becoming the de-facto successor to TypeORM for all TypeORM users. I can imagine that some will want to switch if we do this right. But we will be very clear about the strict scope of the fork as primarily exiting to serve Vendure's needs. This is necessary for us to be able to maintain it sustainably.

Impact

Forking TypeORM would have the following impact on Vendure users (non-exhaustive list - feedback welcome):

1. In all your plugin code that uses TypeORM APIs would need to update to the new package name in imports. I checked a real-world large project and we have 27 imports in total across 30 plugins. So this is probably not a large task for most.
2. In monorepos that use TypeORM outside of the Vendure context, you will have to decide whether to also migrate other projects to our TypeORM fork and update their imports accordingly.

Pros

• With a fork we have the ability to fix the issues which are causing downstream bugs in Vendure
• We eliminate what is currently the number 1 platform risk in our entire tech stack.
• Over time we can refactor the code to improve maintainability, adapt to developments in the JS ecosystem (eg ESM, support for other runtimes)

Cons

• The time and effort needed to maintain another very large code base. Vendure itself is already a huge project which requires significant time to maintain & develop. TypeORM is huge and deals with very complex topics of database performance, security, interoperability etc.
• Fragmentation of the TypeORM ecosystem.

Your Feedback

This is a decision that will affect all Vendure users. Therefore we want to hear from you. What are you thoughts on this topic?

After a period of gathering feedback, assuming that a fork seems to be the best option, we will then plan in detail how it will work and how that will tie in with the Vendure roadmap.

[martijnvdbrug]

Not great, not terrible...

Ideally, we would use a mature library, maintained by 'the world' (I've heard good stories about Sequalize). But, no matter what library we choose, the amount of effort required to migrate will be HUGE, for Vendure and for all consumers with customizations.

Maintaining a vendure-typeorm fork is easier now, but the entire maintenance burden will land on Vendure Core team + community. I have no idea how much time is going into maintenance for such a fork, is there sense of this?

Can I simplify it like this?

• Creating a fork is easier and less impactful for Vendure and Developers
• Creating a fork might take more time in the long run

[tianyingchun]

why not migrated to prisma?

[taxilian]

On the pro column for maintaining your own fork, if the TypeORM community does get a real successor you could still switch back to that and not lose much time and work. On the other hand, if you migrate to a totally different library and then TypeORM picks up again you'd have to switch things back to use it.

Rough decision. Personally I'd rather use MongoDB, but I know I'll be in the extreme minority there ;-)

[taxilian]

Thinking about this a bit more, there is another question to ask:

What is the cost of switching? What is the cost of changing your decision later?

What is the cost of doing your own fork? What is the cost of changing your decision later?

It seems like doing your own fork has a very small cost right now and changing from that to a different framework in 6 months or a year if that becomes worthwhile isn't really going to be much more "expensive" than if you switch now. In other words, if the best long term choice isn't clear now then it may make sense to go with the cheapest option since it won't be more "expensive" later to fix vs now. Technical debt is a beast, but by staying with what we have you don't increase it by a huge amount, at least for the project itself. I suppose the same can't be said for the people using it who may need to update their code to work with the new vendure later.

I think my vote would be to stick with your own fork and keep it to just bugfixes and/or required features while you wait to see if typeorm is going to pick up again. If it doesn't then you can still make the change later on.

[arrrrny]

I used mikro-orm with Nestjs before. It is very similar to type-orm. Back in the time when I was using it was faster than typeorm. Reason for my db heavy project. I think this can also be a good opportunity to decouple pieces in the core system and use only repository and services, and implement db operations as high level details. I think core being this much tightly coupled to a DB system makes it rigid and fragile. I would like to help if you decide a greenfield SOLID project.

[pleerock]

@michaelbromley fork is completely okay, but isn't required, if there are people willing to maintain (most important, safely) original TypeORM repo - I'm open to provide necessary permissions to do so. I was always open to such initiative, and many people tried to take over TypeORM maintenance over past years, but they failed to do so (current situation you see with @giosueDelgado and his team seems, again, similar situation). I think people highly underestimate the complexity of the maintenance.

I completely trust you @michaelbromley (and evaluate your dependency on TypeORM) and if you'll to build a trusted team who can take over original TypeORM fork maintenance - I'm open to it.

[arrrrny]

@michaelbromley fork is completely okay, but isn't required, if there are people willing to maintain (most important, safely) original TypeORM repo - I'm open to provide necessary permissions to do so. I was always open to such initiative, and many people tried to take over TypeORM maintenance over past years, but they failed to do so (current situation you see with @giosueDelgado and his team seems, again, similar situation). I think people highly underestimate the complexity of the maintenance.

I completely trust you @michaelbromley (and evaluate your dependency on TypeORM) and if you'll to build a trusted team who can take over original TypeORM fork maintenance - I'm open to it.

Thats bold and SOLID @pleerock . @michaelbromley is building a phonemenal open source e-commerce framework. You are in good hands

[michaelbromley]

@pleerock Thank you for weighing in on this issue!

I think this proposal is very interesting for us too. We are highly invested in seeing TypeORM succeed.

I think people highly underestimate the complexity of the maintenance.

I can imagine. And this is a mistake I'd like to avoid. To get a proper estimate of what it would take to take over maintenance of the TypeORM project, I'd love to chat with you if possible. You can email me at m.bromley at vendure . io and maybe we can arrange something?

[Draykee]

My first thought was: Why not reach out to the current mainterners of typeorm first to learn more about the scope and maybe get access to the repository - but I see it's already happening.

Me vote would also go to continue with typeorm and fix, what is necessary for vendure.

[michaelbromley]

Update: no need to fork! typeorm/typeorm#3267 (comment)