feat: support v1 of TypeORM#2562
Conversation
TypeORM v1 ignores unknown properties at runtime, so stripping the NestJS-level `name` property is not needed.
- Remove Connection || DataSource fallback (was creating redundant provider in v1) - Revert createDataSourceFactory destructuring back to original options.* access pattern (TypeORM ignores unknown properties) - Remove unnecessary `as any` casts on Connection (already untyped)
CommonJS compilation makes `import { Connection } from 'typeorm'`
resolve to undefined at runtime when the export doesn't exist in v1.
Runtime guards (`if (Connection)`) are sufficient — no require trick
needed. Reverts devDep to 0.3.28 (compile against 0.3 types).
Verified: unit tests pass against both typeorm 0.3.28 and v1 nightly.
We compile against 0.3.28 where DataSource and DataSourceOptions have the name property, so casts are not needed.
The fallback to DEFAULT_DATA_SOURCE_NAME was a behavior change — keep the original logic where missing name causes a no-op.
^0.3.0 || ^1.0.0-0 covers 0.3.x and all 1.x including prereleases. The previous >=0.3.0 was too broad and didn't match v1 prereleases.
Drop entities-metadata spec (tests unchanged file) and remove duplicate getDataSourceToken test case.
There was a problem hiding this comment.
Pull request overview
Updates the NestJS TypeORM integration to be compatible with TypeORM v1 by removing reliance on deprecated APIs and adjusting module option typing/token generation to align with TypeORM 1.0 changes.
Changes:
- Broaden TypeORM peer dependency range to allow
^1.0.0-0in addition to^0.3.0. - Update core module datasource creation/initialization logic to always use
DataSource. - Remove
@EntityRepositoryusage from test repositories and add NestJS-levelname?: stringoption to module options.
Reviewed changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| tests/src/photo/schema/photo-schema.repository.ts | Removes deprecated TypeORM @EntityRepository usage in test custom repository. |
| tests/src/photo/photo.repository.ts | Removes deprecated TypeORM @EntityRepository usage in test custom repository. |
| package.json | Expands TypeORM peer dependency range to include v1 prereleases. |
| package-lock.json | Updates lockfile peer dependency metadata (currently inconsistent with package.json). |
| lib/typeorm-core.module.ts | Removes createConnection fallback and standardizes on DataSource creation/initialization. |
| lib/interfaces/typeorm-options.interface.ts | Adds NestJS-level name?: string to options to compensate for its removal from TypeORM 1.0 options. |
| lib/common/typeorm.utils.ts | Removes Connection token fallback and adjusts token/name helpers for TypeORM v1 compatibility. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Per PR feedback from @alumni — -dev is more descriptive than -0 and covers nightlies, beta, and future stable releases.
| import { Repository } from 'typeorm'; | ||
| import { Photo } from './photo.entity'; | ||
|
|
||
| @EntityRepository(Photo) |
There was a problem hiding this comment.
I think the alternative would be Repository.extend(...), but for that you would need a DataSource - in NestJS that can be done only with some dynamic provider. If the tests are correct, I would expect them to fail now (please check by running them locally).
IMO you can leave EntityRepository for now in the tests since this repo still needs typeorm@0.3 in its dev deps.
|
LGTM |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: #2556
What is the new behavior?
Does this PR introduce a breaking change?
Other information