feat(mongo)!: remove exported internal types by alumni · Pull Request #12037 · typeorm/typeorm

alumni · 2026-02-24T00:10:33Z

Description of change

TypeORM was exporting all (internally declared) MongoDB types, including things like UpdateOptions or ConnectionOptions which in TypeORM also exist or used to exist.

Ideally, we should avoid export * from ... and use export { Thing } from ... to make sure we are exporting only what we want.

To prevent shadowing our own types and polluting the TypeORM exports, I completely removed the MongoDB types. The users can import them from MongoDB if they need, they would be more accurate anyway.

Pull-Request Checklist

Code is up-to-date with the master branch
This pull request links relevant issues as Fixes #00000
There are new or updated tests validating the change (tests/**.test.ts)
Documentation has been updated to reflect this change (docs/docs/**.md)

qodo-free-for-open-source-projects · 2026-02-24T00:10:54Z

User description

Description of change

TypeORM was exporting all MongoDB types, including things like UpdateOptions or ConnectionOptions which in TypeORM exist or used to exist as well.

To prevent shadowing our own types and polluting the TypeORM exports, I completely removed the MongoDB types. The users can import them from MongoDB if they need, they would be more accurate anyway.

Pull-Request Checklist

Code is up-to-date with the master branch
This pull request links relevant issues as Fixes #00000
There are new or updated tests validating the change (tests/**.test.ts)
Documentation has been updated to reflect this change (docs/docs/**.md)

PR Type

Enhancement

Description

Remove exported MongoDB internal types from TypeORM
Users now import ObjectId directly from mongodb package
Update all test and sample files to use new import pattern
Fix variable naming and documentation references

Diagram Walkthrough

flowchart LR
  A["src/driver/mongodb/typings.ts exports"] -->|removed| B["TypeORM index.ts"]
  C["mongodb package"] -->|import ObjectId| D["User code"]
  E["Test/Sample files"] -->|update imports| D
  B -->|no longer exports| F["ObjectId and other MongoDB types"]

File Walkthrough

Relevant files

Enhancement

30 files

index.ts `Remove MongoDB typings export`	+1/-2
Post.ts `Update ObjectId import source`	+2/-3
Post.ts `Update ObjectId import source`	+2/-4
Post.ts `Update ObjectId import source`	+2/-4
Post.ts `Update ObjectId import source`	+2/-4
Post.ts `Update ObjectId import source`	+2/-5
Post.ts `Update ObjectId import source`	+2/-5
Post.ts `Update ObjectId import source`	+7/-5
Post.ts `Update ObjectId import source`	+2/-4
PostWithUnderscoreId.ts `Update ObjectId import source`	+2/-4
Post.ts `Update ObjectId import source`	+2/-4
Post.ts `Update ObjectId import source`	+8/-6
Event.ts `Update ObjectId import source`	+2/-4
User.ts `Update ObjectId import source`	+2/-4
User.ts `Update ObjectId import source`	+2/-4
Product.ts `Update ObjectId import source`	+2/-1
Book.ts `Update ObjectId import source`	+2/-1
config.entity.ts `Update ObjectId import source`	+2/-4
item.entity.ts `Update ObjectId import source`	+2/-4
Post.ts `Update ObjectId import source`	+2/-3
PostV2.ts `Update ObjectId import source`	+2/-3
issue-6552.test.ts `Use direct ObjectId import in tests`	+5/-12
Warn.ts `Update ObjectId import source`	+2/-1
Configuration.ts `Update ObjectId import source`	+2/-6
Post.ts `Update ObjectId import source`	+2/-4
post.entity.ts `Update ObjectId import source`	+1/-1
value.ts `Update ObjectId import source`	+2/-1
Post.ts `Update ObjectId import source`	+2/-1
Post.ts `Update ObjectId import source`	+2/-4
Post.ts `Update ObjectId import source`	+7/-4

Refactoring

3 files

MongoEntityManager.ts `Rename variable for clarity`	+7/-7
issue-7852.test.ts `Fix variable naming convention`	+3/-3
mongodb-entity-change-in-subscribers.test.ts `Reorganize imports`	+2/-3

Documentation

5 files

EntitySchemaColumnOptions.ts `Update documentation formatting`	+1/-1
mongodb.md `Update ObjectId import examples`	+6/-3
1-entities.md `Update documentation formatting`	+1/-1
8-migration-v1.md `Add MongoDB migration guide`	+4/-0
3-decorator-reference.md `Update decorator documentation`	+2/-2

Bug_fix

1 files

issue-6900.test.ts `Fix type casting and method calls`	+8/-7

Configuration_changes

1 files

eslint.config.mjs `Reorder eslint ignore patterns`	+1/-1

pkg-pr-new · 2026-02-24T00:11:29Z

typeorm-sql-js-example

npm i https://pkg.pr.new/typeorm/typeorm@12037

commit: 4f2c4fc

qodo-free-for-open-source-projects · 2026-02-24T00:11:49Z

PR Code Suggestions ✨

Latest suggestions up to 5c17f3a

Category	Suggestion	Impact
Possible issue	Preserve backward-compatible named export alias Add back the aliased export for `RepositoryUpdateOptions` to maintain backward compatibility after changing to a wildcard export. src/index.ts [118] export * from "./repository/UpdateOptions" +export { UpdateOptions as RepositoryUpdateOptions } from "./repository/UpdateOptions" Apply / Chat Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies an undocumented breaking change where the `RepositoryUpdateOptions` alias is removed, which could impact users upgrading the library.	Medium
General	Pass explicit empty filter to countDocuments Add an explicit empty filter `{}` to the `countDocuments()` call to improve code clarity and explicitly match the original behavior. test/github-issues/6900/issue-6900.test.ts [88] -await client.db("foo").collection("warnings").countDocuments(), +await client.db("foo").collection("warnings").countDocuments({}), Apply / Chat Suggestion importance[1-10]: 3 __ Why: The suggestion correctly notes that an explicit empty filter improves code clarity, though the functionality remains unchanged as `countDocuments()` defaults to counting all documents.	Low
Update

Previous suggestions

Suggestions up to commit 40ec139

Category	Suggestion	Impact
Possible issue	Prevent potential runtime errors from undefined IDs Filter out `undefined` values from the mapped `ids` array in the `findByIds` method to prevent potential runtime errors when querying MongoDB. src/entity-manager/MongoEntityManager.ts [200-219] const objectIdClass = PlatformTools.load("mongodb").ObjectId query["_id"] = { - $in: ids.map((id) => { - if (typeof id === "string") { - return new objectIdClass(id) - } - - if (typeof id === "object") { - if (id instanceof objectIdClass) { - return id + $in: ids + .map((id) => { + if (typeof id === "string") { + return new objectIdClass(id) } - const propertyName = metadata.objectIdColumn!.propertyName + if (typeof id === "object" && id !== null) { + if (id instanceof objectIdClass) { + return id + } - if (id[propertyName] instanceof objectIdClass) { - return id[propertyName] + const propertyName = metadata.objectIdColumn!.propertyName + + if (id[propertyName] instanceof objectIdClass) { + return id[propertyName] + } } - } - }), + return undefined + }) + .filter((id) => id !== undefined), } Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies that the `.map()` call can produce `undefined` values, which could cause runtime errors. Filtering these values improves the robustness of the `findByIds` method.	Low
General	Cache ObjectId class Cache the MongoDB `ObjectId` class in a static property on `MongoEntityManager` to avoid repeated calls to `PlatformTools.load()`. src/entity-manager/MongoEntityManager.ts [190-200] -async findByIds<Entity>( - entityClassOrName: EntityTarget<Entity>, - ids: any[], - optionsOrConditions?: FindManyOptions<Entity> \| Partial<Entity>, -): Promise<Entity[]> { - const metadata = this.connection.getMetadata(entityClassOrName) - const query = - this.convertFindManyOptionsOrConditionsToMongodbQuery( - optionsOrConditions, - ) \|\| {} - const objectIdClass = PlatformTools.load("mongodb").ObjectId - query["_id"] = { ... } - ... -} +// Add at class level: +private static MongoObjectId = PlatformTools.load("mongodb").ObjectId +// Then inside methods: +const objectIdClass = MongoEntityManager.MongoObjectId + Suggestion importance[1-10]: 2 __ Why: The suggestion proposes caching the `ObjectId` class to avoid repeated dynamic loads, which is a minor performance and style improvement. However, the performance gain is likely negligible.	Low

qodo-free-for-open-source-projects · 2026-02-24T00:18:40Z

Code Review by Qodo

🐞 Bugs (83) 📘 Rule violations (47) 📎 Requirement gaps (0)

1. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;amp;quot;typeorm&amp;amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;amp;quot;mongodb&amp;amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (121)

4. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

6. Optional mongodb now required 🐞 Bug ⛯ Reliability

Description

MongoDataSourceOptions now imports types from the optional peer dependency mongodb, and
DataSourceOptions publicly includes MongoDataSourceOptions, forcing TypeScript consumers to
resolve mongodb even when they don’t use the MongoDB driver. This breaks compilation for projects
that omit mongodb (despite it being marked optional).

Code

src/driver/mongodb/MongoDataSourceOptions.ts[R1-2]

+import type { ReadPreference } from "mongodb"
import type { BaseDataSourceOptions } from "../../data-source/BaseDataSourceOptions"
-import type { ReadPreference } from "./typings"

Evidence

TypeORM’s exported DataSourceOptions union always references MongoDataSourceOptions; after this
PR, MongoDataSourceOptions imports ReadPreference from mongodb. Since mongodb is still
declared as an *optional* peer dependency, TypeScript consumers that don’t install it will fail to
resolve the mongodb module during type-checking even if they only use non-Mongo drivers.

src/driver/mongodb/MongoDataSourceOptions.ts[1-7]
src/data-source/DataSourceOptions.ts[8-31]
src/index.ts[142-146]
package.json[168-200]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM’s public `.d.ts` now depends on the external `mongodb` module because `MongoDataSourceOptions` imports `ReadPreference` from `mongodb`, while `DataSourceOptions` (exported from `typeorm`) always includes `MongoDataSourceOptions` in its union. Since `mongodb` remains an *optional* peer dependency, TypeScript consumers who don’t install `mongodb` will hit module-resolution errors during type-checking.
## Issue Context
Historically TypeORM avoided importing from optional DB clients in its public type surface by shipping internal typings (e.g. the removed `src/driver/mongodb/typings.ts`). This PR switches several MongoDB-facing types to import directly from `mongodb`, which is incompatible with keeping `mongodb` optional for TS consumers.
## Fix Focus Areas
- src/driver/mongodb/MongoDataSourceOptions.ts[1-3]
- src/data-source/DataSourceOptions.ts[1-31]
- package.json[168-200]
- src/entity-manager/MongoEntityManager.ts[17-40]
- src/repository/MongoRepository.ts[11-35]
- src/driver/mongodb/MongoQueryRunner.ts[17-40]
- src/schema-builder/MongoSchemaBuilder.ts[1-6]
## Suggested approaches
1) **Preferred (keep mongodb optional):**
- Replace `import type { ReadPreference } from &amp;amp;amp;quot;mongodb&amp;amp;amp;quot;` with an internal, non-exported type definition (or `unknown`/string union) so that TypeORM’s exported `DataSourceOptions` does not require resolving `mongodb`.
- Similarly, consider replacing other `import type { ... } from &amp;amp;amp;quot;mongodb&amp;amp;amp;quot;` in exported classes/types with internal type stubs.
2) **If you want to require mongodb for TS users:**
- Update `package.json` to make `mongodb` non-optional (remove `peerDependenciesMeta.mongodb.optional`) and document this as a breaking change.
3) **Architectural isolation:**
- Move MongoDB-specific exports/types behind a separate entrypoint (e.g. `typeorm/mongodb`) so importing `typeorm` doesn’t pull in `mongodb` types.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

7. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

8. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

9. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;amp;amp;quot;typeorm&amp;amp;amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;amp;amp;quot;mongodb&amp;amp;amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

10. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

11. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

12. ObjectId type surface mismatch 🐞 Bug ✓ Correctness

Description

Docs now instruct users to import ObjectId from mongodb, but many public TypeORM APIs (e.g.,
Repository.update/delete and EntityId) still reference TypeORM’s internal ObjectId type from
src/driver/mongodb/bson.typings.ts. This continues to leak internal MongoDB/BSON types into the
public API and may force consumers into deep imports or type mismatches versus mongodb.ObjectId.

Code

src/repository/Repository.ts[R14-15]

+import type { ObjectId } from "../driver/mongodb/bson.typings"
import type { FindOptionsWhere } from "../find-options/FindOptionsWhere"

Evidence
TypeORM documentation tells users to use mongodb.ObjectId, but TypeORM’s own exported Repository
APIs model criteria with ObjectId imported from TypeORM’s internal driver/mongodb/bson.typings.
Additionally, EntityId is defined in terms of this internal ObjectId, so it will appear in
public method signatures (e.g., EntityManager signatures using EntityId).
docs/docs/drivers/mongodb.md[99-107]
src/repository/Repository.ts[14-15]
src/repository/Repository.ts[370-381]
src/repository/EntityId.ts[1-3]
src/driver/mongodb/bson.typings.ts[37-79]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docs now instruct importing `ObjectId` from `mongodb`, but TypeORM’s public APIs still reference an internal `ObjectId` type declared in `src/driver/mongodb/bson.typings.ts`. This leaks internal types into the public surface and may cause consumer confusion/type mismatch.
## Issue Context
- `Repository.update/delete/...` signatures include `ObjectId`.
- `EntityId` includes `ObjectId`.
- `FindOptionsWhere/Select/Order/Relations` have conditional branches keyed off TypeORM’s internal `ObjectId`.
- Docs tell users to use `mongodb.ObjectId`.
## Fix Focus Areas
- src/repository/EntityId.ts[1-3]
- src/repository/Repository.ts[14-15]
- src/repository/Repository.ts[370-381]
- src/repository/BaseEntity.ts[13-14]
- src/find-options/FindOptionsWhere.ts[1-27]
- src/find-options/FindOptionsSelect.ts[1-25]
- src/find-options/FindOptionsOrder.ts[1-25]
- src/find-options/FindOptionsRelations.ts[1-25]
- docs/docs/drivers/mongodb.md[99-107]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

13. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

14. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

15. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;amp;amp;quot;typeorm&amp;amp;amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;amp;amp;quot;mongodb&amp;amp;amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

16. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

17. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

18. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation to...

coveralls · 2026-02-24T00:39:50Z

coverage: 74.651% (-5.6%) from 80.291%
when pulling 70baf4d on alumni:refactor/remove-exported-mongo-types
into 056ee2d on typeorm:master.

alumni · 2026-02-24T00:55:00Z

I'm not sure how those two files had 100% coverage since we don't really use anything except ObjectId and MongoClient. I'm thinking to remove them as well since it's just useless code now, I'd probably need to make a few things private though.

qodo-free-for-open-source-projects · 2026-02-24T22:03:31Z

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (2) 📎 Requirement gaps (0)

1. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness ⭐ New

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
MongoDB docs still show `import { ... ObjectId ... } from &quot;typeorm&quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.

### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &quot;mongodb&quot;`, but one later block remains unchanged.

### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;quot;./driver/mongodb/typings&amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

4. databaseConnection double-cast to MongoClient 📘 Rule violation ✓ Correctness ⭐ New

Description

The test uses a double type-cast (as unknown as MongoClient) to bypass TypeScript typing for
databaseConnection. This introduces type-bypass noise and risks masking real typing issues rather
than fixing the underlying type mismatch.

Code

test/github-issues/6900/issue-6900.test.ts[43]
+            .databaseConnection as unknown as MongoClient

Evidence
PR Compliance ID 4 requires avoiding type-bypass noise such as casts used to work around typing
issues. The changed lines explicitly introduce a double-cast of databaseConnection to
MongoClient, which is a type-bypass pattern.
Rule 4: Remove AI-generated noise
test/github-issues/6900/issue-6900.test.ts[43-43]
test/github-issues/6900/issue-6900.test.ts[85-85]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The test casts `databaseConnection` using `as unknown as MongoClient`, which is a type-bypass pattern and adds noise.

## Issue Context
This occurs in the MongoDB-related test for issue #6900 when accessing `mongoDriver.queryRunner!.databaseConnection`.

## Fix Focus Areas
- test/github-issues/6900/issue-6900.test.ts[43-43]
- test/github-issues/6900/issue-6900.test.ts[85-85]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

ⓘ The new review experience is currently in Beta. Learn more

qodo-free-for-open-source-projects · 2026-03-02T20:17:17Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

ⓘ The new review experience is currently in Beta. Learn more

qodo-free-for-open-source-projects · 2026-03-02T20:22:55Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

ⓘ The new review experience is currently in Beta. Learn more

qodo-free-for-open-source-projects · 2026-03-02T21:55:51Z

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (3) 📎 Requirement gaps (0)

1. Optional mongodb now required 🐞 Bug ⛯ Reliability ⭐ New

Description

MongoDataSourceOptions now imports types from the optional peer dependency mongodb, and
DataSourceOptions publicly includes MongoDataSourceOptions, forcing TypeScript consumers to
resolve mongodb even when they don’t use the MongoDB driver. This breaks compilation for projects
that omit mongodb (despite it being marked optional).

Code

src/driver/mongodb/MongoDataSourceOptions.ts[R1-2]

+import type { ReadPreference } from "mongodb"
import type { BaseDataSourceOptions } from "../../data-source/BaseDataSourceOptions"
-import type { ReadPreference } from "./typings"

Evidence

TypeORM’s exported DataSourceOptions union always references MongoDataSourceOptions; after this
PR, MongoDataSourceOptions imports ReadPreference from mongodb. Since mongodb is still
declared as an *optional* peer dependency, TypeScript consumers that don’t install it will fail to
resolve the mongodb module during type-checking even if they only use non-Mongo drivers.

src/driver/mongodb/MongoDataSourceOptions.ts[1-7]
src/data-source/DataSourceOptions.ts[8-31]
src/index.ts[142-146]
package.json[168-200]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM’s public `.d.ts` now depends on the external `mongodb` module because `MongoDataSourceOptions` imports `ReadPreference` from `mongodb`, while `DataSourceOptions` (exported from `typeorm`) always includes `MongoDataSourceOptions` in its union. Since `mongodb` remains an *optional* peer dependency, TypeScript consumers who don’t install `mongodb` will hit module-resolution errors during type-checking.

## Issue Context
Historically TypeORM avoided importing from optional DB clients in its public type surface by shipping internal typings (e.g. the removed `src/driver/mongodb/typings.ts`). This PR switches several MongoDB-facing types to import directly from `mongodb`, which is incompatible with keeping `mongodb` optional for TS consumers.

## Fix Focus Areas
- src/driver/mongodb/MongoDataSourceOptions.ts[1-3]
- src/data-source/DataSourceOptions.ts[1-31]
- package.json[168-200]
- src/entity-manager/MongoEntityManager.ts[17-40]
- src/repository/MongoRepository.ts[11-35]
- src/driver/mongodb/MongoQueryRunner.ts[17-40]
- src/schema-builder/MongoSchemaBuilder.ts[1-6]

## Suggested approaches
1) **Preferred (keep mongodb optional):**
  - Replace `import type { ReadPreference } from &quot;mongodb&quot;` with an internal, non-exported type definition (or `unknown`/string union) so that TypeORM’s exported `DataSourceOptions` does not require resolving `mongodb`.
  - Similarly, consider replacing other `import type { ... } from &quot;mongodb&quot;` in exported classes/types with internal type stubs.

2) **If you want to require mongodb for TS users:**
  - Update `package.json` to make `mongodb` non-optional (remove `peerDependenciesMeta.mongodb.optional`) and document this as a breaking change.

3) **Architectural isolation:**
  - Move MongoDB-specific exports/types behind a separate entrypoint (e.g. `typeorm/mongodb`) so importing `typeorm` doesn’t pull in `mongodb` types.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;quot;./driver/mongodb/typings&amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (3)

4. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;quot;typeorm&amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;quot;mongodb&amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

6. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

7. databaseConnection double-cast to MongoClient 📘 Rule violation ✓ Correctness

Description

The test uses a double type-cast (as unknown as MongoClient) to bypass TypeScript typing for
databaseConnection. This introduces type-bypass noise and risks masking real typing issues rather
than fixing the underlying type mismatch.

Code

test/github-issues/6900/issue-6900.test.ts[43]
+            .databaseConnection as unknown as MongoClient

Evidence
PR Compliance ID 4 requires avoiding type-bypass noise such as casts used to work around typing
issues. The changed lines explicitly introduce a double-cast of databaseConnection to
MongoClient, which is a type-bypass pattern.
Rule 4: Remove AI-generated noise
test/github-issues/6900/issue-6900.test.ts[43-43]
test/github-issues/6900/issue-6900.test.ts[85-85]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The test casts `databaseConnection` using `as unknown as MongoClient`, which is a type-bypass pattern and adds noise.
## Issue Context
This occurs in the MongoDB-related test for issue #6900 when accessing `mongoDriver.queryRunner!.databaseConnection`.
## Fix Focus Areas
- test/github-issues/6900/issue-6900.test.ts[43-43]
- test/github-issues/6900/issue-6900.test.ts[85-85]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

ⓘ The new review experience is currently in Beta. Learn more

qodo-free-for-open-source-projects · 2026-03-02T22:02:25Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

ⓘ The new review experience is currently in Beta. Learn more

qodo-free-for-open-source-projects · 2026-03-02T22:17:35Z

Code Review by Qodo

🐞 Bugs (8) 📘 Rule violations (6) 📎 Requirement gaps (0)

1. ObjectId type surface mismatch 🐞 Bug ✓ Correctness ⭐ New

Description

Docs now instruct users to import ObjectId from mongodb, but many public TypeORM APIs (e.g.,
Repository.update/delete and EntityId) still reference TypeORM’s internal ObjectId type from
src/driver/mongodb/bson.typings.ts. This continues to leak internal MongoDB/BSON types into the
public API and may force consumers into deep imports or type mismatches versus mongodb.ObjectId.

Code

src/repository/Repository.ts[R14-15]

+import type { ObjectId } from "../driver/mongodb/bson.typings"
import type { FindOptionsWhere } from "../find-options/FindOptionsWhere"

Evidence
TypeORM documentation tells users to use mongodb.ObjectId, but TypeORM’s own exported Repository
APIs model criteria with ObjectId imported from TypeORM’s internal driver/mongodb/bson.typings.
Additionally, EntityId is defined in terms of this internal ObjectId, so it will appear in
public method signatures (e.g., EntityManager signatures using EntityId).
docs/docs/drivers/mongodb.md[99-107]
src/repository/Repository.ts[14-15]
src/repository/Repository.ts[370-381]
src/repository/EntityId.ts[1-3]
src/driver/mongodb/bson.typings.ts[37-79]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docs now instruct importing `ObjectId` from `mongodb`, but TypeORM’s public APIs still reference an internal `ObjectId` type declared in `src/driver/mongodb/bson.typings.ts`. This leaks internal types into the public surface and may cause consumer confusion/type mismatch.

## Issue Context
- `Repository.update/delete/...` signatures include `ObjectId`.
- `EntityId` includes `ObjectId`.
- `FindOptionsWhere/Select/Order/Relations` have conditional branches keyed off TypeORM’s internal `ObjectId`.
- Docs tell users to use `mongodb.ObjectId`.

## Fix Focus Areas
- src/repository/EntityId.ts[1-3]
- src/repository/Repository.ts[14-15]
- src/repository/Repository.ts[370-381]
- src/repository/BaseEntity.ts[13-14]
- src/find-options/FindOptionsWhere.ts[1-27]
- src/find-options/FindOptionsSelect.ts[1-25]
- src/find-options/FindOptionsOrder.ts[1-25]
- src/find-options/FindOptionsRelations.ts[1-25]
- docs/docs/drivers/mongodb.md[99-107]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;quot;./driver/mongodb/typings&amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (9)

4. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;quot;typeorm&amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;quot;mongodb&amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

6. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

7. Optional mongodb now required 🐞 Bug ⛯ Reliability

Description

MongoDataSourceOptions now imports types from the optional peer dependency mongodb, and
DataSourceOptions publicly includes MongoDataSourceOptions, forcing TypeScript consumers to
resolve mongodb even when they don’t use the MongoDB driver. This breaks compilation for projects
that omit mongodb (despite it being marked optional).

Code

src/driver/mongodb/MongoDataSourceOptions.ts[R1-2]

+import type { ReadPreference } from "mongodb"
import type { BaseDataSourceOptions } from "../../data-source/BaseDataSourceOptions"
-import type { ReadPreference } from "./typings"

Evidence

TypeORM’s exported DataSourceOptions union always references MongoDataSourceOptions; after this
PR, MongoDataSourceOptions imports ReadPreference from mongodb. Since mongodb is still
declared as an *optional* peer dependency, TypeScript consumers that don’t install it will fail to
resolve the mongodb module during type-checking even if they only use non-Mongo drivers.

src/driver/mongodb/MongoDataSourceOptions.ts[1-7]
src/data-source/DataSourceOptions.ts[8-31]
src/index.ts[142-146]
package.json[168-200]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM’s public `.d.ts` now depends on the external `mongodb` module because `MongoDataSourceOptions` imports `ReadPreference` from `mongodb`, while `DataSourceOptions` (exported from `typeorm`) always includes `MongoDataSourceOptions` in its union. Since `mongodb` remains an *optional* peer dependency, TypeScript consumers who don’t install `mongodb` will hit module-resolution errors during type-checking.
## Issue Context
Historically TypeORM avoided importing from optional DB clients in its public type surface by shipping internal typings (e.g. the removed `src/driver/mongodb/typings.ts`). This PR switches several MongoDB-facing types to import directly from `mongodb`, which is incompatible with keeping `mongodb` optional for TS consumers.
## Fix Focus Areas
- src/driver/mongodb/MongoDataSourceOptions.ts[1-3]
- src/data-source/DataSourceOptions.ts[1-31]
- package.json[168-200]
- src/entity-manager/MongoEntityManager.ts[17-40]
- src/repository/MongoRepository.ts[11-35]
- src/driver/mongodb/MongoQueryRunner.ts[17-40]
- src/schema-builder/MongoSchemaBuilder.ts[1-6]
## Suggested approaches
1) **Preferred (keep mongodb optional):**
 - Replace `import type { ReadPreference } from &amp;quot;mongodb&amp;quot;` with an internal, non-exported type definition (or `unknown`/string union) so that TypeORM’s exported `DataSourceOptions` does not require resolving `mongodb`.
 - Similarly, consider replacing other `import type { ... } from &amp;quot;mongodb&amp;quot;` in exported classes/types with internal type stubs.
2) **If you want to require mongodb for TS users:**
 - Update `package.json` to make `mongodb` non-optional (remove `peerDependenciesMeta.mongodb.optional`) and document this as a breaking change.
3) **Architectural isolation:**
 - Move MongoDB-specific exports/types behind a separate entrypoint (e.g. `typeorm/mongodb`) so importing `typeorm` doesn’t pull in `mongodb` types.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

8. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

9. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

10. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

11. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

12. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

13. databaseConnection double-cast to MongoClient 📘 Rule violation ✓ Correctness

Description

The test uses a double type-cast (as unknown as MongoClient) to bypass TypeScript typing for
databaseConnection. This introduces type-bypass noise and risks masking real typing issues rather
than fixing the underlying type mismatch.

Code

test/github-issues/6900/issue-6900.test.ts[43]
+            .databaseConnection as unknown as MongoClient

Evidence
PR Compliance ID 4 requires avoiding type-bypass noise such as casts used to work around typing
issues. The changed lines explicitly introduce a double-cast of databaseConnection to
MongoClient, which is a type-bypass pattern.
Rule 4: Remove AI-generated noise
test/github-issues/6900/issue-6900.test.ts[43-43]
test/github-issues/6900/issue-6900.test.ts[85-85]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The test casts `databaseConnection` using `as unknown as MongoClient`, which is a type-bypass pattern and adds noise.
## Issue Context
This occurs in the MongoDB-related test for issue #6900 when accessing `mongoDriver.queryRunner!.databaseConnection`.
## Fix Focus Areas
- test/github-issues/6900/issue-6900.test.ts[43-43]
- test/github-issues/6900/issue-6900.test.ts[85-85]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

14. databaseConnection double-cast to MongoClient 📘 Rule violation ✓ Correctness

Description

The test uses a double type-cast (as unknown as MongoClient) to bypass TypeScript typing for
databaseConnection. This introduces type-bypass noise and risks masking real typing issues rather
than fixing the underlying type mismatch.

Code

test/github-issues/6900/issue-6900.test.ts[43]
+            .databaseConnection as unknown as MongoClient

Evidence
PR Compliance ID 4 requires avoiding type-bypass noise such as casts used to work around typing
issues. The changed lines explicitly introduce a double-cast of databaseConnection to
MongoClient, which is a type-bypass pattern.
Rule 4: Remove AI-generated noise
test/github-issues/6900/issue-6900.test.ts[43-43]
test/github-issues/6900/issue-6900.test.ts[85-85]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The test casts `databaseConnection` using `as unknown as MongoClient`, which is a type-bypass pattern and adds noise.
## Issue Context
This occurs in the MongoDB-related test for issue #6900 when accessing `mongoDriver.queryRunner!.databaseConnection`.
## Fix Focus Areas
- test/github-issues/6900/issue-6900.test.ts[43-43]
- test/github-issues/6900/issue-6900.test.ts[85-85]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

ⓘ The new review experience is currently in Beta. Learn more

qodo-free-for-open-source-projects · 2026-03-02T22:23:21Z

Code Review by Qodo

🐞 Bugs (16) 📘 Rule violations (12) 📎 Requirement gaps (0)

1. 7437 test assertion mismatch 🐞 Bug ✓ Correctness ⭐ New

Description

The updated #7437 test uses deep.equal and expects useUnifiedTopology, url, and type to be
absent, but DriverUtils.buildMongoDBDriverOptions merges the original input (including url) and
parseMongoDBConnectionUrl copies all query params (including useUnifiedTopology) into the
result. This makes the test inconsistent with current implementation and likely to fail.

Code

test/github-issues/7437/issue-7437.test.ts[R11-20]

+        expect(options).to.deep.equal({
+            host: "test-primary.example.com",
+            username: "testuser",
+            password: "testpwd",
+            port: 27017,
+            database: "testdb",
+            retryWrites: "true",
+            w: "majority",
+            // useUnifiedTopology is invalid
+        })

Evidence

The test expects an exact object with only host/auth/port/database/retryWrites/w. However,
buildMongoDBDriverOptions returns Object.assign({}, options, urlDriverOptions), so the returned
object includes url from the input; additionally parseMongoDBConnectionUrl always sets type
and copies every query param key/value into the returned object, so useUnifiedTopology=true will
be present.

test/github-issues/7437/issue-7437.test.ts[6-21]
src/driver/DriverUtils.ts[88-114]
src/driver/DriverUtils.ts[292-307]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The #7437 test expects `DriverUtils.buildMongoDBDriverOptions` to return an object *exactly equal* to a subset of parsed fields and to omit `useUnifiedTopology`, `url`, and `type`. The current implementation includes `url` (from input), `type` (from parsing), and all query params (including `useUnifiedTopology`).

## Issue Context
This is likely to fail CI and also makes the test brittle to unrelated additions of parsed options.

## Fix Focus Areas
- test/github-issues/7437/issue-7437.test.ts[6-21]
- src/driver/DriverUtils.ts[88-114]
- src/driver/DriverUtils.ts[233-307]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;quot;./driver/mongodb/typings&amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (21)

4. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;quot;typeorm&amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;quot;mongodb&amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

6. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

7. Optional mongodb now required 🐞 Bug ⛯ Reliability

Description

MongoDataSourceOptions now imports types from the optional peer dependency mongodb, and
DataSourceOptions publicly includes MongoDataSourceOptions, forcing TypeScript consumers to
resolve mongodb even when they don’t use the MongoDB driver. This breaks compilation for projects
that omit mongodb (despite it being marked optional).

Code

src/driver/mongodb/MongoDataSourceOptions.ts[R1-2]

+import type { ReadPreference } from "mongodb"
import type { BaseDataSourceOptions } from "../../data-source/BaseDataSourceOptions"
-import type { ReadPreference } from "./typings"

Evidence

TypeORM’s exported DataSourceOptions union always references MongoDataSourceOptions; after this
PR, MongoDataSourceOptions imports ReadPreference from mongodb. Since mongodb is still
declared as an *optional* peer dependency, TypeScript consumers that don’t install it will fail to
resolve the mongodb module during type-checking even if they only use non-Mongo drivers.

src/driver/mongodb/MongoDataSourceOptions.ts[1-7]
src/data-source/DataSourceOptions.ts[8-31]
src/index.ts[142-146]
package.json[168-200]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM’s public `.d.ts` now depends on the external `mongodb` module because `MongoDataSourceOptions` imports `ReadPreference` from `mongodb`, while `DataSourceOptions` (exported from `typeorm`) always includes `MongoDataSourceOptions` in its union. Since `mongodb` remains an *optional* peer dependency, TypeScript consumers who don’t install `mongodb` will hit module-resolution errors during type-checking.
## Issue Context
Historically TypeORM avoided importing from optional DB clients in its public type surface by shipping internal typings (e.g. the removed `src/driver/mongodb/typings.ts`). This PR switches several MongoDB-facing types to import directly from `mongodb`, which is incompatible with keeping `mongodb` optional for TS consumers.
## Fix Focus Areas
- src/driver/mongodb/MongoDataSourceOptions.ts[1-3]
- src/data-source/DataSourceOptions.ts[1-31]
- package.json[168-200]
- src/entity-manager/MongoEntityManager.ts[17-40]
- src/repository/MongoRepository.ts[11-35]
- src/driver/mongodb/MongoQueryRunner.ts[17-40]
- src/schema-builder/MongoSchemaBuilder.ts[1-6]
## Suggested approaches
1) **Preferred (keep mongodb optional):**
 - Replace `import type { ReadPreference } from &amp;quot;mongodb&amp;quot;` with an internal, non-exported type definition (or `unknown`/string union) so that TypeORM’s exported `DataSourceOptions` does not require resolving `mongodb`.
 - Similarly, consider replacing other `import type { ... } from &amp;quot;mongodb&amp;quot;` in exported classes/types with internal type stubs.
2) **If you want to require mongodb for TS users:**
 - Update `package.json` to make `mongodb` non-optional (remove `peerDependenciesMeta.mongodb.optional`) and document this as a breaking change.
3) **Architectural isolation:**
 - Move MongoDB-specific exports/types behind a separate entrypoint (e.g. `typeorm/mongodb`) so importing `typeorm` doesn’t pull in `mongodb` types.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

8. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

9. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

10. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

11. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

12. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

13. ObjectId type surface mismatch 🐞 Bug ✓ Correctness

Description

Docs now instruct users to import ObjectId from mongodb, but many public TypeORM APIs (e.g.,
Repository.update/delete and EntityId) still reference TypeORM’s internal ObjectId type from
src/driver/mongodb/bson.typings.ts. This continues to leak internal MongoDB/BSON types into the
public API and may force consumers into deep imports or type mismatches versus mongodb.ObjectId.

Code

src/repository/Repository.ts[R14-15]

+import type { ObjectId } from "../driver/mongodb/bson.typings"
import type { FindOptionsWhere } from "../find-options/FindOptionsWhere"

Evidence
TypeORM documentation tells users to use mongodb.ObjectId, but TypeORM’s own exported Repository
APIs model criteria with ObjectId imported from TypeORM’s internal driver/mongodb/bson.typings.
Additionally, EntityId is defined in terms of this internal ObjectId, so it will appear in
public method signatures (e.g., EntityManager signatures using EntityId).
docs/docs/drivers/mongodb.md[99-107]
src/repository/Repository.ts[14-15]
src/repository/Repository.ts[370-381]
src/repository/EntityId.ts[1-3]
src/driver/mongodb/bson.typings.ts[37-79]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docs now instruct importing `ObjectId` from `mongodb`, but TypeORM’s public APIs still reference an internal `ObjectId` type declared in `src/driver/mongodb/bson.typings.ts`. This leaks internal types into the public surface and may cause consumer confusion/type mismatch.
## Issue Context
- `Repository.update/delete/...` signatures include `ObjectId`.
- `EntityId` includes `ObjectId`.
- `FindOptionsWhere/Select/Order/Relations` have conditional branches keyed off TypeORM’s internal `ObjectId`.
- Docs tell users to use `mongodb.ObjectId`.
## Fix Focus Areas
- src/repository/EntityId.ts[1-3]
- src/repository/Repository.ts[14-15]
- src/repository/Repository.ts[370-381]
- src/repository/BaseEntity.ts[13-14]
- src/find-options/FindOptionsWhere.ts[1-27]
- src/find-options/FindOptionsSelect.ts[1-25]
- src/find-options/FindOptionsOrder.ts[1-25]
- src/find-options/FindOptionsRelations.ts[1-25]
- docs/docs/drivers/mongodb.md[99-107]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

14. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

15. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

16. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

17. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

18. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) ...

qodo-free-for-open-source-projects · 2026-03-02T22:28:49Z

Code Review by Qodo

🐞 Bugs (16) 📘 Rule violations (12) 📎 Requirement gaps (0)

1. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;quot;./driver/mongodb/typings&amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;quot;typeorm&amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;quot;mongodb&amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (20)

4. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

6. Optional mongodb now required 🐞 Bug ⛯ Reliability

Description

MongoDataSourceOptions now imports types from the optional peer dependency mongodb, and
DataSourceOptions publicly includes MongoDataSourceOptions, forcing TypeScript consumers to
resolve mongodb even when they don’t use the MongoDB driver. This breaks compilation for projects
that omit mongodb (despite it being marked optional).

Code

src/driver/mongodb/MongoDataSourceOptions.ts[R1-2]

+import type { ReadPreference } from "mongodb"
import type { BaseDataSourceOptions } from "../../data-source/BaseDataSourceOptions"
-import type { ReadPreference } from "./typings"

Evidence

TypeORM’s exported DataSourceOptions union always references MongoDataSourceOptions; after this
PR, MongoDataSourceOptions imports ReadPreference from mongodb. Since mongodb is still
declared as an *optional* peer dependency, TypeScript consumers that don’t install it will fail to
resolve the mongodb module during type-checking even if they only use non-Mongo drivers.

src/driver/mongodb/MongoDataSourceOptions.ts[1-7]
src/data-source/DataSourceOptions.ts[8-31]
src/index.ts[142-146]
package.json[168-200]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM’s public `.d.ts` now depends on the external `mongodb` module because `MongoDataSourceOptions` imports `ReadPreference` from `mongodb`, while `DataSourceOptions` (exported from `typeorm`) always includes `MongoDataSourceOptions` in its union. Since `mongodb` remains an *optional* peer dependency, TypeScript consumers who don’t install `mongodb` will hit module-resolution errors during type-checking.
## Issue Context
Historically TypeORM avoided importing from optional DB clients in its public type surface by shipping internal typings (e.g. the removed `src/driver/mongodb/typings.ts`). This PR switches several MongoDB-facing types to import directly from `mongodb`, which is incompatible with keeping `mongodb` optional for TS consumers.
## Fix Focus Areas
- src/driver/mongodb/MongoDataSourceOptions.ts[1-3]
- src/data-source/DataSourceOptions.ts[1-31]
- package.json[168-200]
- src/entity-manager/MongoEntityManager.ts[17-40]
- src/repository/MongoRepository.ts[11-35]
- src/driver/mongodb/MongoQueryRunner.ts[17-40]
- src/schema-builder/MongoSchemaBuilder.ts[1-6]
## Suggested approaches
1) **Preferred (keep mongodb optional):**
 - Replace `import type { ReadPreference } from &amp;quot;mongodb&amp;quot;` with an internal, non-exported type definition (or `unknown`/string union) so that TypeORM’s exported `DataSourceOptions` does not require resolving `mongodb`.
 - Similarly, consider replacing other `import type { ... } from &amp;quot;mongodb&amp;quot;` in exported classes/types with internal type stubs.
2) **If you want to require mongodb for TS users:**
 - Update `package.json` to make `mongodb` non-optional (remove `peerDependenciesMeta.mongodb.optional`) and document this as a breaking change.
3) **Architectural isolation:**
 - Move MongoDB-specific exports/types behind a separate entrypoint (e.g. `typeorm/mongodb`) so importing `typeorm` doesn’t pull in `mongodb` types.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

7. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

8. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

9. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

10. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

11. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

12. ObjectId type surface mismatch 🐞 Bug ✓ Correctness

Description

Docs now instruct users to import ObjectId from mongodb, but many public TypeORM APIs (e.g.,
Repository.update/delete and EntityId) still reference TypeORM’s internal ObjectId type from
src/driver/mongodb/bson.typings.ts. This continues to leak internal MongoDB/BSON types into the
public API and may force consumers into deep imports or type mismatches versus mongodb.ObjectId.

Code

src/repository/Repository.ts[R14-15]

+import type { ObjectId } from "../driver/mongodb/bson.typings"
import type { FindOptionsWhere } from "../find-options/FindOptionsWhere"

Evidence
TypeORM documentation tells users to use mongodb.ObjectId, but TypeORM’s own exported Repository
APIs model criteria with ObjectId imported from TypeORM’s internal driver/mongodb/bson.typings.
Additionally, EntityId is defined in terms of this internal ObjectId, so it will appear in
public method signatures (e.g., EntityManager signatures using EntityId).
docs/docs/drivers/mongodb.md[99-107]
src/repository/Repository.ts[14-15]
src/repository/Repository.ts[370-381]
src/repository/EntityId.ts[1-3]
src/driver/mongodb/bson.typings.ts[37-79]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docs now instruct importing `ObjectId` from `mongodb`, but TypeORM’s public APIs still reference an internal `ObjectId` type declared in `src/driver/mongodb/bson.typings.ts`. This leaks internal types into the public surface and may cause consumer confusion/type mismatch.
## Issue Context
- `Repository.update/delete/...` signatures include `ObjectId`.
- `EntityId` includes `ObjectId`.
- `FindOptionsWhere/Select/Order/Relations` have conditional branches keyed off TypeORM’s internal `ObjectId`.
- Docs tell users to use `mongodb.ObjectId`.
## Fix Focus Areas
- src/repository/EntityId.ts[1-3]
- src/repository/Repository.ts[14-15]
- src/repository/Repository.ts[370-381]
- src/repository/BaseEntity.ts[13-14]
- src/find-options/FindOptionsWhere.ts[1-27]
- src/find-options/FindOptionsSelect.ts[1-25]
- src/find-options/FindOptionsOrder.ts[1-25]
- src/find-options/FindOptionsRelations.ts[1-25]
- docs/docs/drivers/mongodb.md[99-107]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

13. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

14. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

15. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

16. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

17. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

18. Optional mongodb now required 🐞 Bug ⛯ Reliability

Description

MongoDataSourceOptions now imports types from the optional peer dependency mongodb, and
DataSourceOptions publicly includes MongoDataSourceOptions, forcing TypeScript consumers to
resolve mongodb even when they don’t use the MongoDB driver. This breaks compilation for projects
that omit mongodb (despite it being marked optional).

Code

src/driver/mongodb/MongoDataSourceOptions.ts[R1-2]

+import type { ReadPreference } from "mongodb"
import type { BaseDataSourceOptions } from "../../data-source/BaseDataSourceOptions"
-import type { ReadPreference } from "./typings"

Evidence

TypeORM’s exported DataSourceOptions union always references MongoDataSourceOptions; after this
PR, MongoDataSourceOptions imports ReadPreference from mongodb. Since mongodb is still
declared as an *optional* peer dependency, TypeScript consumers that don’t install it will fail to
resolve the mongodb module during type-checking even if they only use non-Mongo drivers.

src/driver/mongodb/MongoDataSourceOptions.ts[1-7]
src/data-source/DataSourceOptions.ts[8-31]
src/index.ts[142-146]
package.json[168-200]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM’s public `.d.ts` now depends on the external `mongodb` module because `MongoDataSourceOptions` imports `ReadPreference` from `mongodb`, while `DataSourceOptions` (exported fro...

qodo-free-for-open-source-projects · 2026-03-02T22:36:22Z

Code Review by Qodo

🐞 Bugs (27) 📘 Rule violations (18) 📎 Requirement gaps (0)

1. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;quot;./driver/mongodb/typings&amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;quot;typeorm&amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;quot;mongodb&amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (37)

4. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

6. Optional mongodb now required 🐞 Bug ⛯ Reliability

Description

MongoDataSourceOptions now imports types from the optional peer dependency mongodb, and
DataSourceOptions publicly includes MongoDataSourceOptions, forcing TypeScript consumers to
resolve mongodb even when they don’t use the MongoDB driver. This breaks compilation for projects
that omit mongodb (despite it being marked optional).

Code

src/driver/mongodb/MongoDataSourceOptions.ts[R1-2]

+import type { ReadPreference } from "mongodb"
import type { BaseDataSourceOptions } from "../../data-source/BaseDataSourceOptions"
-import type { ReadPreference } from "./typings"

Evidence

TypeORM’s exported DataSourceOptions union always references MongoDataSourceOptions; after this
PR, MongoDataSourceOptions imports ReadPreference from mongodb. Since mongodb is still
declared as an *optional* peer dependency, TypeScript consumers that don’t install it will fail to
resolve the mongodb module during type-checking even if they only use non-Mongo drivers.

src/driver/mongodb/MongoDataSourceOptions.ts[1-7]
src/data-source/DataSourceOptions.ts[8-31]
src/index.ts[142-146]
package.json[168-200]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM’s public `.d.ts` now depends on the external `mongodb` module because `MongoDataSourceOptions` imports `ReadPreference` from `mongodb`, while `DataSourceOptions` (exported from `typeorm`) always includes `MongoDataSourceOptions` in its union. Since `mongodb` remains an *optional* peer dependency, TypeScript consumers who don’t install `mongodb` will hit module-resolution errors during type-checking.
## Issue Context
Historically TypeORM avoided importing from optional DB clients in its public type surface by shipping internal typings (e.g. the removed `src/driver/mongodb/typings.ts`). This PR switches several MongoDB-facing types to import directly from `mongodb`, which is incompatible with keeping `mongodb` optional for TS consumers.
## Fix Focus Areas
- src/driver/mongodb/MongoDataSourceOptions.ts[1-3]
- src/data-source/DataSourceOptions.ts[1-31]
- package.json[168-200]
- src/entity-manager/MongoEntityManager.ts[17-40]
- src/repository/MongoRepository.ts[11-35]
- src/driver/mongodb/MongoQueryRunner.ts[17-40]
- src/schema-builder/MongoSchemaBuilder.ts[1-6]
## Suggested approaches
1) **Preferred (keep mongodb optional):**
 - Replace `import type { ReadPreference } from &amp;quot;mongodb&amp;quot;` with an internal, non-exported type definition (or `unknown`/string union) so that TypeORM’s exported `DataSourceOptions` does not require resolving `mongodb`.
 - Similarly, consider replacing other `import type { ... } from &amp;quot;mongodb&amp;quot;` in exported classes/types with internal type stubs.
2) **If you want to require mongodb for TS users:**
 - Update `package.json` to make `mongodb` non-optional (remove `peerDependenciesMeta.mongodb.optional`) and document this as a breaking change.
3) **Architectural isolation:**
 - Move MongoDB-specific exports/types behind a separate entrypoint (e.g. `typeorm/mongodb`) so importing `typeorm` doesn’t pull in `mongodb` types.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

7. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

8. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

9. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

10. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

11. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

12. ObjectId type surface mismatch 🐞 Bug ✓ Correctness

Description

Docs now instruct users to import ObjectId from mongodb, but many public TypeORM APIs (e.g.,
Repository.update/delete and EntityId) still reference TypeORM’s internal ObjectId type from
src/driver/mongodb/bson.typings.ts. This continues to leak internal MongoDB/BSON types into the
public API and may force consumers into deep imports or type mismatches versus mongodb.ObjectId.

Code

src/repository/Repository.ts[R14-15]

+import type { ObjectId } from "../driver/mongodb/bson.typings"
import type { FindOptionsWhere } from "../find-options/FindOptionsWhere"

Evidence
TypeORM documentation tells users to use mongodb.ObjectId, but TypeORM’s own exported Repository
APIs model criteria with ObjectId imported from TypeORM’s internal driver/mongodb/bson.typings.
Additionally, EntityId is defined in terms of this internal ObjectId, so it will appear in
public method signatures (e.g., EntityManager signatures using EntityId).
docs/docs/drivers/mongodb.md[99-107]
src/repository/Repository.ts[14-15]
src/repository/Repository.ts[370-381]
src/repository/EntityId.ts[1-3]
src/driver/mongodb/bson.typings.ts[37-79]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docs now instruct importing `ObjectId` from `mongodb`, but TypeORM’s public APIs still reference an internal `ObjectId` type declared in `src/driver/mongodb/bson.typings.ts`. This leaks internal types into the public surface and may cause consumer confusion/type mismatch.
## Issue Context
- `Repository.update/delete/...` signatures include `ObjectId`.
- `EntityId` includes `ObjectId`.
- `FindOptionsWhere/Select/Order/Relations` have conditional branches keyed off TypeORM’s internal `ObjectId`.
- Docs tell users to use `mongodb.ObjectId`.
## Fix Focus Areas
- src/repository/EntityId.ts[1-3]
- src/repository/Repository.ts[14-15]
- src/repository/Repository.ts[370-381]
- src/repository/BaseEntity.ts[13-14]
- src/find-options/FindOptionsWhere.ts[1-27]
- src/find-options/FindOptionsSelect.ts[1-25]
- src/find-options/FindOptionsOrder.ts[1-25]
- src/find-options/FindOptionsRelations.ts[1-25]
- docs/docs/drivers/mongodb.md[99-107]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

13. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

14. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

15. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

16. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

17. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

18. Optional mongodb now required 🐞 Bug ⛯ Reliability

Description

MongoDataSourceOptions now imports types from the optional peer dependency mongodb, and
DataSourceOptions publicly includes MongoDataSourceOptions, forcing TypeScript consumers to
resolve mongodb even when they don’t use the MongoDB driver. This breaks compilation for projects
that omit mongodb (despite it being marked optional).

Code

src/driver/mongodb/MongoDataSourceOptions.ts[R1-2]

+import type { ReadPreference } from "mongodb"
import type { BaseDataSourceOptions } from "../../data-source/BaseDataSourceOptions"
-import type { ReadPreference } from "./typings"

Evidence

TypeORM’s exported DataSourceOptions union always references MongoDataSourceOptions; after this
PR, MongoDataSourceOptions imports ReadPreference from mongodb. Since mongodb is still
declared as an *optional* peer dependency, TypeScript consumers that don’t install it will fail to
resolve the mongodb module during type-checking even if they only use non-Mongo drivers.

src/driver/mongodb/MongoDataSourceOptions.ts[1-7]
src/data-source/DataSourceOptions.ts[8-31]
src/index.ts[142-146]
package.json[168-200]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM’s public `.d.ts` now depends on the external `mongodb` module because `MongoDataSourceOptions` imports `ReadPreference` from `mongodb`, while `DataSourceOptions` (exported fro...

qodo-free-for-open-source-projects · 2026-03-03T14:41:20Z

Code Review by Qodo

🐞 Bugs (48) 📘 Rule violations (31) 📎 Requirement gaps (0)

1. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;quot;./driver/mongodb/typings&amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;quot;typeorm&amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;quot;mongodb&amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (71)

4. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

6. Optional mongodb now required 🐞 Bug ⛯ Reliability

Description

MongoDataSourceOptions now imports types from the optional peer dependency mongodb, and
DataSourceOptions publicly includes MongoDataSourceOptions, forcing TypeScript consumers to
resolve mongodb even when they don’t use the MongoDB driver. This breaks compilation for projects
that omit mongodb (despite it being marked optional).

Code

src/driver/mongodb/MongoDataSourceOptions.ts[R1-2]

+import type { ReadPreference } from "mongodb"
import type { BaseDataSourceOptions } from "../../data-source/BaseDataSourceOptions"
-import type { ReadPreference } from "./typings"

Evidence

TypeORM’s exported DataSourceOptions union always references MongoDataSourceOptions; after this
PR, MongoDataSourceOptions imports ReadPreference from mongodb. Since mongodb is still
declared as an *optional* peer dependency, TypeScript consumers that don’t install it will fail to
resolve the mongodb module during type-checking even if they only use non-Mongo drivers.

src/driver/mongodb/MongoDataSourceOptions.ts[1-7]
src/data-source/DataSourceOptions.ts[8-31]
src/index.ts[142-146]
package.json[168-200]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM’s public `.d.ts` now depends on the external `mongodb` module because `MongoDataSourceOptions` imports `ReadPreference` from `mongodb`, while `DataSourceOptions` (exported from `typeorm`) always includes `MongoDataSourceOptions` in its union. Since `mongodb` remains an *optional* peer dependency, TypeScript consumers who don’t install `mongodb` will hit module-resolution errors during type-checking.
## Issue Context
Historically TypeORM avoided importing from optional DB clients in its public type surface by shipping internal typings (e.g. the removed `src/driver/mongodb/typings.ts`). This PR switches several MongoDB-facing types to import directly from `mongodb`, which is incompatible with keeping `mongodb` optional for TS consumers.
## Fix Focus Areas
- src/driver/mongodb/MongoDataSourceOptions.ts[1-3]
- src/data-source/DataSourceOptions.ts[1-31]
- package.json[168-200]
- src/entity-manager/MongoEntityManager.ts[17-40]
- src/repository/MongoRepository.ts[11-35]
- src/driver/mongodb/MongoQueryRunner.ts[17-40]
- src/schema-builder/MongoSchemaBuilder.ts[1-6]
## Suggested approaches
1) **Preferred (keep mongodb optional):**
 - Replace `import type { ReadPreference } from &amp;quot;mongodb&amp;quot;` with an internal, non-exported type definition (or `unknown`/string union) so that TypeORM’s exported `DataSourceOptions` does not require resolving `mongodb`.
 - Similarly, consider replacing other `import type { ... } from &amp;quot;mongodb&amp;quot;` in exported classes/types with internal type stubs.
2) **If you want to require mongodb for TS users:**
 - Update `package.json` to make `mongodb` non-optional (remove `peerDependenciesMeta.mongodb.optional`) and document this as a breaking change.
3) **Architectural isolation:**
 - Move MongoDB-specific exports/types behind a separate entrypoint (e.g. `typeorm/mongodb`) so importing `typeorm` doesn’t pull in `mongodb` types.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

7. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

8. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

9. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

10. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

11. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

12. ObjectId type surface mismatch 🐞 Bug ✓ Correctness

Description

Docs now instruct users to import ObjectId from mongodb, but many public TypeORM APIs (e.g.,
Repository.update/delete and EntityId) still reference TypeORM’s internal ObjectId type from
src/driver/mongodb/bson.typings.ts. This continues to leak internal MongoDB/BSON types into the
public API and may force consumers into deep imports or type mismatches versus mongodb.ObjectId.

Code

src/repository/Repository.ts[R14-15]

+import type { ObjectId } from "../driver/mongodb/bson.typings"
import type { FindOptionsWhere } from "../find-options/FindOptionsWhere"

Evidence
TypeORM documentation tells users to use mongodb.ObjectId, but TypeORM’s own exported Repository
APIs model criteria with ObjectId imported from TypeORM’s internal driver/mongodb/bson.typings.
Additionally, EntityId is defined in terms of this internal ObjectId, so it will appear in
public method signatures (e.g., EntityManager signatures using EntityId).
docs/docs/drivers/mongodb.md[99-107]
src/repository/Repository.ts[14-15]
src/repository/Repository.ts[370-381]
src/repository/EntityId.ts[1-3]
src/driver/mongodb/bson.typings.ts[37-79]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docs now instruct importing `ObjectId` from `mongodb`, but TypeORM’s public APIs still reference an internal `ObjectId` type declared in `src/driver/mongodb/bson.typings.ts`. This leaks internal types into the public surface and may cause consumer confusion/type mismatch.
## Issue Context
- `Repository.update/delete/...` signatures include `ObjectId`.
- `EntityId` includes `ObjectId`.
- `FindOptionsWhere/Select/Order/Relations` have conditional branches keyed off TypeORM’s internal `ObjectId`.
- Docs tell users to use `mongodb.ObjectId`.
## Fix Focus Areas
- src/repository/EntityId.ts[1-3]
- src/repository/Repository.ts[14-15]
- src/repository/Repository.ts[370-381]
- src/repository/BaseEntity.ts[13-14]
- src/find-options/FindOptionsWhere.ts[1-27]
- src/find-options/FindOptionsSelect.ts[1-25]
- src/find-options/FindOptionsOrder.ts[1-25]
- src/find-options/FindOptionsRelations.ts[1-25]
- docs/docs/drivers/mongodb.md[99-107]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

13. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

14. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

15. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

16. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

17. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

18. Optional mongodb now required 🐞 Bug ⛯ Reliability

Description

MongoDataSourceOptions now imports types from the optional peer dependency mongodb, and
DataSourceOptions publicly includes MongoDataSourceOptions, forcing TypeScript consumers to
resolve mongodb even when they don’t use the MongoDB driver. This breaks compilation for projects
that omit mongodb (despite it being marked optional).

Code

src/driver/mongodb/MongoDataSourceOptions.ts[R1-2]

+import type { ReadPreference } from "mongodb"
import type { BaseDataSourceOptions } from "../../data-source/BaseDataSourceOptions"
-import type { ReadPreference } from "./typings"

Evidence

TypeORM’s exported DataSourceOptions union always references MongoDataSourceOptions; after this
PR, MongoDataSourceOptions imports ReadPreference from mongodb. Since mongodb is still
declared as an *optional* peer dependency, TypeScript consumers that don’t install it will fail to
resolve the mongodb module during type-checking even if they only use non-Mongo drivers.

src/driver/mongodb/MongoDataSourceOptions.ts[1-7]
src/data-source/DataSourceOptions.ts[8-31]
src/index.ts[142-146]
package.json[168-200]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM’s public `.d.ts` now depends on the external `mongodb` module because `MongoDataSourceOptions` imports `ReadPreference` from `mongodb`, while `DataSourceOptions` (exported fro...

qodo-free-for-open-source-projects · 2026-03-03T14:48:09Z

Code Review by Qodo

🐞 Bugs (61) 📘 Rule violations (36) 📎 Requirement gaps (0)

1. Optional peer type leak 🐞 Bug ⛯ Reliability ⭐ New

Description

Core public TypeORM types now import type from the optional peer dependency mongodb, which can
cause TS builds to fail for consumers that don’t install mongodb (even if they don’t use the
MongoDB driver). This is a repo-wide API-surface coupling because these types are re-exported from
src/index.ts.

Code

src/repository/EntityId.ts[R1-3]

+import type { ObjectId } from "mongodb"

export type EntityId = string | number | Date | ObjectId

Evidence

mongodb is explicitly an optional peer dependency, but TypeORM’s root type surface imports
ObjectId from it and re-exports those types from the main entrypoint; TypeScript will attempt to
resolve the mongodb module while loading TypeORM’s .d.ts, yielding module-resolution errors when
mongodb isn’t installed (unless consumers use workarounds like skipLibCheck).

package.json[168-201]
src/repository/EntityId.ts[1-3]
src/index.ts[80-119]
src/repository/BaseEntity.ts[358-374]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
TypeORM’s exported `.d.ts` now contains `import type ... from &quot;mongodb&quot;` in core/shared types (e.g., `EntityId`, `FindOptionsWhere`, `BaseEntity` APIs). Because `mongodb` is an **optional** peer dependency, consumers not using MongoDB commonly won’t have it installed, and TypeScript module resolution can fail when loading TypeORM’s type declarations.

### Issue Context
- `mongodb` is marked optional via `peerDependenciesMeta`.
- The affected types are re-exported from `src/index.ts`, so they’re part of the root `typeorm` type surface.

### Fix Focus Areas
- src/repository/EntityId.ts[1-3]
- src/find-options/FindOptionsWhere.ts[1-28]
- src/repository/BaseEntity.ts[1-20]
- src/index.ts[80-119]
- package.json[168-201]

### Suggested direction
- Introduce a TypeORM-owned structural type (e.g., `export interface ObjectIdLike { toHexString(): string }`) and use it in unions/conditionals instead of importing `mongodb`’s `ObjectId`.
- Keep MongoDB driver-specific option types either:
 - expressed structurally (string unions / minimal interfaces), or
 - isolated to a separate subpath export (e.g., `typeorm/mongodb`) so the main `typeorm` types don’t import `mongodb`.
- If you *intend* to require `mongodb` for all TS consumers, remove its `optional` flag in `peerDependenciesMeta` and document clearly (but this is usually undesirable for a multi-driver ORM).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;quot;./driver/mongodb/typings&amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (89)

4. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;quot;typeorm&amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;quot;mongodb&amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

6. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

7. Optional mongodb now required 🐞 Bug ⛯ Reliability

Description

MongoDataSourceOptions now imports types from the optional peer dependency mongodb, and
DataSourceOptions publicly includes MongoDataSourceOptions, forcing TypeScript consumers to
resolve mongodb even when they don’t use the MongoDB driver. This breaks compilation for projects
that omit mongodb (despite it being marked optional).

Code

src/driver/mongodb/MongoDataSourceOptions.ts[R1-2]

+import type { ReadPreference } from "mongodb"
import type { BaseDataSourceOptions } from "../../data-source/BaseDataSourceOptions"
-import type { ReadPreference } from "./typings"

Evidence

TypeORM’s exported DataSourceOptions union always references MongoDataSourceOptions; after this
PR, MongoDataSourceOptions imports ReadPreference from mongodb. Since mongodb is still
declared as an *optional* peer dependency, TypeScript consumers that don’t install it will fail to
resolve the mongodb module during type-checking even if they only use non-Mongo drivers.

src/driver/mongodb/MongoDataSourceOptions.ts[1-7]
src/data-source/DataSourceOptions.ts[8-31]
src/index.ts[142-146]
package.json[168-200]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM’s public `.d.ts` now depends on the external `mongodb` module because `MongoDataSourceOptions` imports `ReadPreference` from `mongodb`, while `DataSourceOptions` (exported from `typeorm`) always includes `MongoDataSourceOptions` in its union. Since `mongodb` remains an *optional* peer dependency, TypeScript consumers who don’t install `mongodb` will hit module-resolution errors during type-checking.
## Issue Context
Historically TypeORM avoided importing from optional DB clients in its public type surface by shipping internal typings (e.g. the removed `src/driver/mongodb/typings.ts`). This PR switches several MongoDB-facing types to import directly from `mongodb`, which is incompatible with keeping `mongodb` optional for TS consumers.
## Fix Focus Areas
- src/driver/mongodb/MongoDataSourceOptions.ts[1-3]
- src/data-source/DataSourceOptions.ts[1-31]
- package.json[168-200]
- src/entity-manager/MongoEntityManager.ts[17-40]
- src/repository/MongoRepository.ts[11-35]
- src/driver/mongodb/MongoQueryRunner.ts[17-40]
- src/schema-builder/MongoSchemaBuilder.ts[1-6]
## Suggested approaches
1) **Preferred (keep mongodb optional):**
 - Replace `import type { ReadPreference } from &amp;quot;mongodb&amp;quot;` with an internal, non-exported type definition (or `unknown`/string union) so that TypeORM’s exported `DataSourceOptions` does not require resolving `mongodb`.
 - Similarly, consider replacing other `import type { ... } from &amp;quot;mongodb&amp;quot;` in exported classes/types with internal type stubs.
2) **If you want to require mongodb for TS users:**
 - Update `package.json` to make `mongodb` non-optional (remove `peerDependenciesMeta.mongodb.optional`) and document this as a breaking change.
3) **Architectural isolation:**
 - Move MongoDB-specific exports/types behind a separate entrypoint (e.g. `typeorm/mongodb`) so importing `typeorm` doesn’t pull in `mongodb` types.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

8. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

9. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

10. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

11. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

12. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;amp;quot;./driver/mongodb/typings&amp;amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

13. ObjectId type surface mismatch 🐞 Bug ✓ Correctness

Description

Docs now instruct users to import ObjectId from mongodb, but many public TypeORM APIs (e.g.,
Repository.update/delete and EntityId) still reference TypeORM’s internal ObjectId type from
src/driver/mongodb/bson.typings.ts. This continues to leak internal MongoDB/BSON types into the
public API and may force consumers into deep imports or type mismatches versus mongodb.ObjectId.

Code

src/repository/Repository.ts[R14-15]

+import type { ObjectId } from "../driver/mongodb/bson.typings"
import type { FindOptionsWhere } from "../find-options/FindOptionsWhere"

Evidence
TypeORM documentation tells users to use mongodb.ObjectId, but TypeORM’s own exported Repository
APIs model criteria with ObjectId imported from TypeORM’s internal driver/mongodb/bson.typings.
Additionally, EntityId is defined in terms of this internal ObjectId, so it will appear in
public method signatures (e.g., EntityManager signatures using EntityId).
docs/docs/drivers/mongodb.md[99-107]
src/repository/Repository.ts[14-15]
src/repository/Repository.ts[370-381]
src/repository/EntityId.ts[1-3]
src/driver/mongodb/bson.typings.ts[37-79]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docs now instruct importing `ObjectId` from `mongodb`, but TypeORM’s public APIs still reference an internal `ObjectId` type declared in `src/driver/mongodb/bson.typings.ts`. This leaks internal types into the public surface and may cause consumer confusion/type mismatch.
## Issue Context
- `Repository.update/delete/...` signatures include `ObjectId`.
- `EntityId` includes `ObjectId`.
- `FindOptionsWhere/Select/Order/Relations` have conditional branches keyed off TypeORM’s internal `ObjectId`.
- Docs tell users to use `mongodb.ObjectId`.
## Fix Focus Areas
- src/repository/EntityId.ts[1-3]
- src/repository/Repository.ts[14-15]
- src/repository/Repository.ts[370-381]
- src/repository/BaseEntity.ts[13-14]
- src/find-options/FindOptionsWhere.ts[1-27]
- src/find-options/FindOptionsSelect.ts[1-25]
- src/find-options/FindOptionsOrder.ts[1-25]
- src/find-options/FindOptionsRelations.ts[1-25]
- docs/docs/drivers/mongodb.md[99-107]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

14. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

15. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/entity-manager/MongoEntityManager.ts[17-58]
- src/entity-manager/EntityManager.ts[814-828]
- src/driver/mongodb/typings.ts[1-5]
- package.json[171-177]
## Suggested approaches (pick one)
1) **Introduce a namespaced export** that avoids polluting root symbols but gives consumers the exact types TypeORM uses, e.g. `export * as MongoDB from &amp;amp;quot;./driver/mongodb/typings&amp;amp;quot;` (or a dedicated `typeorm/mongodb` entrypoint), and update docs to reference that.
2) **Stop exposing internal MongoDB types in public signatures**: refactor Mongo-facing public APIs to use structurally-safe minimal types (`unknown`/`any` for ids/options) or TypeORM-defined wrapper types that do not depend on the copied mongodb typings.
3) If you truly want consumers to use `mongodb` types, then **align TypeORM’s public Mongo API types with `mongodb` package types** via a dedicated optional-types entrypoint that only resolves when `mongodb` is installed, avoiding breaking non-mongo users.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

16. MongoDB docs still use typeorm ObjectId 🐞 Bug ✓ Correctness

Description

After removing ./driver/mongodb/typings from TypeORM’s public exports, the MongoDB driver docs
still contain a code block importing ObjectId from "typeorm". Users following that snippet will
now get a compile error.

Code

src/index.ts[R133-137]

export * from "./schema-builder/options/TableOptions"
export * from "./schema-builder/options/TableUniqueOptions"
export * from "./schema-builder/options/ViewOptions"
-export * from "./driver/mongodb/typings"
export * from "./driver/types/DatabaseType"
export * from "./driver/types/GeoJsonTypes"

Evidence

src/index.ts no longer re-exports MongoDB typings, so ObjectId is no longer a typeorm export;
however the MongoDB docs still show importing it from typeorm in one remaining snippet.

src/index.ts[133-138]
docs/docs/drivers/mongodb.md[171-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MongoDB docs still show `import { ... ObjectId ... } from &amp;amp;quot;typeorm&amp;amp;quot;`, but this PR removes the MongoDB typings re-export from the TypeORM public entrypoint. That example will no longer compile.
### Issue Context
Other code blocks in `docs/docs/drivers/mongodb.md` were updated to `import { ObjectId } from &amp;amp;quot;mongodb&amp;amp;quot;`, but one later block remains unchanged.
### Fix Focus Areas
- docs/docs/drivers/mongodb.md[171-178]
- src/index.ts[133-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

17. RepositoryUpdateOptions removal undocumented 📘 Rule violation ✓ Correctness

Description

The PR changes the public exports by re-exporting UpdateOptions (and implicitly dropping the
previous RepositoryUpdateOptions alias), but the migration/docs updates only mention ObjectId
import changes. Users relying on RepositoryUpdateOptions may have a breaking change without
guidance.

Code

src/index.ts[118]
+export * from "./repository/UpdateOptions"

Evidence

Compliance requires docs updates for user-facing API/usage changes. The PR modifies the public
export surface (export * from "./repository/UpdateOptions"), but the migration guide’s new MongoDB
note only documents ObjectId import changes and does not mention the
UpdateOptions/RepositoryUpdateOptions export change.

Rule 2: Docs updated for user-facing changes
src/index.ts[118-118]
docs/docs/guides/8-migration-v1.md[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public export surface for update options (switching to exporting `UpdateOptions` directly via `export *`), but docs/migration notes only mention the `ObjectId` MongoDB-type change.
## Issue Context
This is a user-facing API change: consumers may have been importing `RepositoryUpdateOptions` and will now need guidance on what to import instead.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[118-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

18. Mongo APIs still use copied types 🐞 Bug ✓ Correctness

Description

MongoEntityManager/EntityManager public signatures still reference the copied internal MongoDB
typings, but the PR removes exporting those types and tells users to import from mongodb. Since
TypeORM’s copied typings are pinned to one mongodb version while peer deps allow multiple versions,
users can hit TS type incompatibilities (especially with class types like ObjectId) when following
the migration guide.

Code

src/index.ts[136]
-export * from "./driver/mongodb/typings"

Evidence

The PR removes the top-level export of ./driver/mongodb/typings, while the migration guide directs
users to import ObjectId from mongodb. However, TypeORM still exposes MongoDB-facing APIs (e.g.,
MongoEntityManager and EntityManager methods) that use ObjectId and many other MongoDB types from
the internal copied typings module. Those typings are explicitly a copy of the mongodb package’s
.d.ts from a specific devDependency version, while TypeORM’s peerDependency range allows mongodb
v5/v6/v7, so the exported TypeORM types can diverge from the user’s installed mongodb types and
become incompatible.

src/index.ts[120-138]
docs/docs/guides/8-migration-v1.md[15-18]
src/index.ts[167-167]
src/entity-manager/MongoEntityManager.ts[17-58]
src/entity-manager/EntityManager.ts[814-828]
src/driver/mongodb/typings.ts[1-5]
package.json[171-177]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeORM no longer exports `./driver/mongodb/typings` from the root entrypoint and docs instruct users to import `ObjectId` from `mongodb`. But TypeORM’s exported MongoDB APIs (e.g., `MongoEntityManager`, `EntityManager.update` criteria types, `MongoRepository`) still reference the **copied** internal MongoDB typings. Because those copied typings are pinned to a specific mongodb version while TypeORM supports mongodb v5/v6/v7 as peer deps, consumers may see TypeScript incompatibilities when using their installed `mongodb` types.
## Issue Context
- Root export of internal typings was removed.
- Migration guide instructs importing `ObjectId` from `mongodb`.
- Public APIs still use types from `../driver/mongodb/typings`.
## Fix Focus Areas
- src/index.ts[120-138]
- docs/docs/guides/8-migration-v1.md[15-18]
- src/index.ts[167-167]
- src/...

qodo-free-for-open-source-projects · 2026-03-08T17:29:18Z

Persistent review updated to latest commit ca01a46

pkuczynski · 2026-03-08T18:11:15Z

src/index.ts

 export * from "./repository/MongoRepository"
 export type * from "./repository/RemoveOptions"
 export type * from "./repository/SaveOptions"
-export type { UpdateOptions as RepositoryUpdateOptions } from "./repository/UpdateOptions"


We should mention this in migratuin guide...

qodo-free-for-open-source-projects · 2026-03-08T18:15:44Z

Persistent review updated to latest commit 4f2c4fc

sonarqubecloud · 2026-03-08T18:26:28Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
2.5% Duplication on New Code

See analysis details on SonarQube Cloud

qodo-free-for-open-source-projects · 2026-03-08T18:33:46Z

Persistent review updated to latest commit 70baf4d

pkuczynski approved these changes Feb 24, 2026

View reviewed changes

gioboa approved these changes Feb 24, 2026

View reviewed changes

alumni force-pushed the refactor/remove-exported-mongo-types branch from 40ec139 to 5c17f3a Compare February 24, 2026 21:57

This was referenced Mar 2, 2026

Release plan for 1.0 #11819

Open

chore(mongo): sync typings with the latest v5 version of the mongodb driver (5.9.2) #11707

Closed

alumni force-pushed the refactor/remove-exported-mongo-types branch from 5c17f3a to 2028ed8 Compare March 2, 2026 20:12

alumni force-pushed the refactor/remove-exported-mongo-types branch from 2028ed8 to 4fb5073 Compare March 2, 2026 21:49

alumni force-pushed the refactor/remove-exported-mongo-types branch from 4fb5073 to 0e85d37 Compare March 2, 2026 22:10

alumni force-pushed the refactor/remove-exported-mongo-types branch from 0e85d37 to e4c8a22 Compare March 2, 2026 22:22

alumni added the discussion label Mar 3, 2026

alumni force-pushed the refactor/remove-exported-mongo-types branch from b6f9079 to ca01a46 Compare March 8, 2026 17:23

alumni removed the discussion label Mar 8, 2026

alumni force-pushed the refactor/remove-exported-mongo-types branch from ca01a46 to 4f2c4fc Compare March 8, 2026 18:08

pkuczynski reviewed Mar 8, 2026

View reviewed changes

refactor(mongo)!: remove exported internal types

70baf4d

alumni force-pushed the refactor/remove-exported-mongo-types branch from 4f2c4fc to 70baf4d Compare March 8, 2026 18:25

alumni merged commit a5c9b4c into typeorm:master Mar 8, 2026
36 of 60 checks passed

github-actions bot added this to the 1.0 milestone Mar 8, 2026

Uh oh!

Conversation

alumni commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of change

Pull-Request Checklist

Uh oh!

qodo-free-for-open-source-projects bot commented Feb 24, 2026

User description

Description of change

Pull-Request Checklist

PR Type

Description

Diagram Walkthrough

File Walkthrough

Uh oh!

pkg-pr-new bot commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qodo-free-for-open-source-projects bot commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Code Suggestions ✨

Previous suggestions

Uh oh!

qodo-free-for-open-source-projects bot commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

coveralls commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alumni commented Feb 24, 2026

Uh oh!

qodo-free-for-open-source-projects bot commented Feb 24, 2026

Code Review by Qodo

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 2, 2026

Code Review by Qodo

Great, no issues found!

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 2, 2026

Code Review by Qodo

Great, no issues found!

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 2, 2026

Code Review by Qodo

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 2, 2026

Code Review by Qodo

Great, no issues found!

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 2, 2026

Code Review by Qodo

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 2, 2026

Code Review by Qodo

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 2, 2026

Code Review by Qodo

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 2, 2026

Code Review by Qodo

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 3, 2026

Code Review by Qodo

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 3, 2026

Code Review by Qodo

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 8, 2026

Uh oh!

pkuczynski Mar 8, 2026

Choose a reason for hiding this comment

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 8, 2026

Uh oh!

sonarqubecloud bot commented Mar 8, 2026

Quality Gate passed

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 8, 2026

alumni commented Feb 24, 2026 •

edited

Loading

pkg-pr-new bot commented Feb 24, 2026 •

edited

Loading

qodo-free-for-open-source-projects bot commented Feb 24, 2026 •

edited

Loading

qodo-free-for-open-source-projects bot commented Feb 24, 2026 •

edited

Loading

coveralls commented Feb 24, 2026 •

edited

Loading