TypeORM โ Google Summer of Code (GSoC) Idea List
This document outlines potential GSoC project ideas for TypeORM. Each idea includes a description, goals, expected outcomes, and difficulty level.
First-Class Polymorphic Relations in TypeORMโ
Descriptionโ
TypeORM currently lacks native support for polymorphic relations (a single relation pointing to multiple entity types). Users rely on workarounds that are hard to type, error-prone, and inconsistent across databases.
Mentorsโ
Goalsโ
- Design a first-class polymorphic relation API for TypeORM
- Ensure compatibility with existing relation decorators
- Provide migration and schema synchronization support
Expected Outcomesโ
- New decorator(s) for polymorphic relations
- QueryBuilder support for polymorphic joins
- Clear documentation and examples
- Backward-compatible implementation
Difficultyโ
Medium - Expected 175 hours
Required Skillsโ
TypeScript, ORM internals, SQL schema design
Improved Type Safety and Inference Across TypeORMโ
Descriptionโ
Despite being written in TypeScript, TypeORM has several weakly typed areas (relations, query builder results, repository methods). Improving type inference would significantly enhance developer experience and correctness.
Mentorsโ
Goalsโ
- Improve relation type inference (lazy and eager relations)
- Strongly type
QueryBuilderresults - Reduce
anyusage in public APIs - Improve generics for
RepositoryandEntityManager
Expected Outcomesโ
- Better compile-time guarantees
- Fewer runtime errors
- Incremental, non-breaking improvements
- Documentation of recommended typing patterns
Difficultyโ
Medium - Expected 175 hours
Required Skillsโ
Advanced TypeScript, generics, library API design
Vector Support: Types, Indexing, and Search Across Databasesโ
Descriptionโ
Vector embeddings are increasingly common in modern applications (AI, search, recommendations). While TypeORM has partial support for vector column types, it lacks a unified and complete solution for vector storage, indexing, and querying across databases.
This project aims to provide end-to-end vector support in TypeORM, covering vector column types, database-specific mappings, vector indexing, and high-level vector search abstractions.
Mentorsโ
Goalsโ
- Add vector column support for remaining databases (e.g. Oracle)
- Investigate SQLite limitations and support
libsqlvectors where possible - Define a consistent, cross-database vector column API
- Implement vector index support where databases allow it
- Expose vector similarity queries via
QueryBuilder - Implement a high-level vector store abstraction on top of repositories
- Optional: explore knowledge-graph-style queries (e.g. SPARQL-inspired APIs)
Expected Outcomesโ
- New
@Column({ type: "vector" })support across databases - Database-specific vector mappings, fallbacks, and limitations
- Cross-database vector index support
- High-level vector search and similarity query APIs
- Extensible architecture for future AI and search-related features
- Clear documentation and examples
Difficultyโ
Medium โ Expected 175 hours
Required Skillsโ
SQL dialects, database internals, TypeORM driver architecture, indexing strategies, query optimization, API design
Modularization of Entity Definition APIsโ
Mentorsโ
Descriptionโ
TypeORM currently supports two different ways to define entities: class-based entities (decorators) and entity schemas. Over time, these two approaches have diverged, with entity schema support often lagging behind class-based entities in features and type safety.
This project focuses on extracting and modularizing entity definition styles into clearer, better-isolated components, with the goal of keeping both approaches in sync and enabling future architectural improvements. Rather than attempting a full monorepo restructuring, the project targets a well-defined and achievable subset of that work.
Goalsโ
- Extract entity definition logic into clearly separated modules or packages
- Improve parity between class-based entities and entity schemas
- Explore a function-based entity definition API with strong type inference
- Reduce duplication between entity definition styles
- Lay groundwork for future modularization (e.g. CLI, logging, caching)
Expected Outcomesโ
- Better synchronization of features between entity schemas and class-based entities
- Cleaner internal abstractions for entity metadata definition
- Improved type inference for nonโclass-based entity definitions
- Clear boundaries that make future refactoring and modularization safer
Difficultyโ
Hard - Expected 350 hours
Required Skillsโ
TypeScript, TypeORM metadata system, API design, large codebase refactoring
SQL Dialect Abstraction for Custom Driver Developmentโ
Descriptionโ
Adding or maintaining database drivers in TypeORM is currently complex and tightly coupled to existing driver implementations. Introducing a clearer SQL dialect abstraction would make it easier to support new databases and reduce duplication across drivers.
This project aims to define and introduce a SQL dialect layer that encapsulates database-specific SQL behavior, enabling easier development of new drivers and better separation of concerns within TypeORM.
Mentorsโ
Goalsโ
- Design a SQL dialect abstraction that captures database-specific behavior
- Extract common SQL generation logic from existing drivers
- Define clear extension points for implementing new dialects
- Document how to build a custom driver using the dialect system
Expected Outcomesโ
- A well-defined SQL dialect interface
- Reduced duplication across existing drivers
- Improved maintainability of current drivers
- Clear pathway for community-contributed database drivers
Difficultyโ
Hard - Expected 350 hours
Required Skillsโ
SQL dialects, database internals, TypeScript, TypeORM driver architecture
Open Call for Community-Proposed Ideasโ
TypeORM welcomes Google Summer of Code project ideas proposed by contributors and community members.
If you have experience with TypeORM and have identified pain points, missing features, or architectural improvements, you are encouraged to suggest a GSoC project idea.
Suggested ideas may include (but are not limited to):
- Improvements to existing drivers or database support
- Performance optimizations
- Developer experience and tooling enhancements
- Documentation or testing infrastructure improvements
- New features
Proposed ideas should include:
- A short problem statement
- Expected outcomes and scope
- Estimated difficulty
- Relevant technical areas (TypeScript, SQL, drivers, etc.)
Community-proposed ideas will be reviewed by maintainers and may be added to the official GSoC project list.
Modern Migration Tooling and Snapshotsโ
Descriptionโ
TypeORMโs migration workflow is currently centered around the CLI, which can be cumbersome in TypeScript-based projects and limits advanced use cases. In addition, projects with long migration histories face slow and error-prone database bootstrapping when setting up new environments.
This project aims to modernize TypeORMโs migration tooling by introducing a programmatic migration generation API and optional schema snapshots. Together, these improvements would make migration generation more flexible and allow faster initialization of new databases without replaying all historical migrations.
Mentorsโ
Goalsโ
- Introduce a programmatic API for generating migrations without relying on the CLI
- Enable customizable migration templates
- Design a schema snapshot mechanism representing the final database structure
- Allow bootstrapping new databases using snapshots while preserving migration history
- Ensure compatibility with existing migration workflows
Expected Outcomesโ
- Improved developer experience for TypeScript and non-CLI workflows
- Faster and more reliable database setup for large projects
- More flexible migration generation and templating
- Clear documentation and recommended usage patterns
Difficultyโ
Medium - Expected 175 Hours
Required Skillsโ
TypeScript, SQL, TypeORM migrations system, CLI internals, API and tooling design
Getting Startedโ
Students interested in contributing to TypeORM as part of Google Summer of Code are encouraged to get involved early. Familiarity with the codebase, contribution workflow, and community practices is strongly recommended before submitting a proposal.
To get started:
- Please join our discord server.
- Read CONTRIBUTING.md.
- Explore the TypeORM repository and documentation to understand its architecture and supported databases.
- Try fixing a small issue or improving documentation to get familiar with the contribution process.