Description

An empty JSDoc block with only an @param tag was added above the local run() helper, adding
noise without improving clarity. This violates the requirement to avoid extra AI-like comments and
keeps the file style unnecessarily verbose.

Code

src/driver/sqlite/SqliteDriver.ts[R156-159]

+        /**
+         *
+         * @param line
+         */

Evidence

PR Compliance ID 4 requires avoiding extra/AI-like comments; the added JSDoc block contains no
description and only an @param tag, making it pure comment noise.

Rule 4: Remove AI-generated noise
src/driver/sqlite/SqliteDriver.ts[155-160]

Agent prompt

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

## Issue description
An empty JSDoc comment block was added above the local `run()` helper in `SqliteDriver`, containing no useful description and only an `@param` tag. This is comment noise and violates the "Remove AI-generated noise" compliance requirement.
## Issue Context
There is already a clear single-line comment explaining the purpose of `run()`, so the empty JSDoc adds verbosity without value.
## Fix Focus Areas
- src/driver/sqlite/SqliteDriver.ts[156-159]

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

Description

This PR removes user-facing exports (Connection/ConnectionOptions) but no documentation updates
are included. Users upgrading may not know how to migrate to DataSource/DataSourceOptions.

Code

src/index.ts[L146-148]

-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"

Evidence

Compliance requires documentation updates for user-facing API/usage changes. The PR removes public
exports in src/index.ts, and the PR description explicitly notes documentation has not been
updated and includes a TODO to update the migration docs.

Rule 2: Docs updated for user-facing changes
src/index.ts[145-149]

Agent prompt

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

## Issue description
User-facing API exports (`Connection` / `ConnectionOptions`) were removed, but this PR does not include documentation changes to guide users to `DataSource` / `DataSourceOptions`.
## Issue Context
The PR description explicitly calls out a TODO to update the "migration to v1" documentation, and the docs checklist item is unchecked.
## Fix Focus Areas
- src/index.ts[145-149]

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

Description

This PR removes user-facing exports (Connection/ConnectionOptions) but no documentation updates
are included. Users upgrading may not know how to migrate to DataSource/DataSourceOptions.

Code

src/index.ts[L146-148]

-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"

Evidence

Compliance requires documentation updates for user-facing API/usage changes. The PR removes public
exports in src/index.ts, and the PR description explicitly notes documentation has not been
updated and includes a TODO to update the migration docs.

Rule 2: Docs updated for user-facing changes
src/index.ts[145-149]

Agent prompt

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

## Issue description
User-facing API exports (`Connection` / `ConnectionOptions`) were removed, but this PR does not include documentation changes to guide users to `DataSource` / `DataSourceOptions`.
## Issue Context
The PR description explicitly calls out a TODO to update the "migration to v1" documentation, and the docs checklist item is unchecked.
## Fix Focus Areas
- src/index.ts[145-149]

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

Description

This PR removes user-facing exports (Connection/ConnectionOptions) but no documentation updates
are included. Users upgrading may not know how to migrate to DataSource/DataSourceOptions.

Code

src/index.ts[L146-148]

-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"

Evidence

Compliance requires documentation updates for user-facing API/usage changes. The PR removes public
exports in src/index.ts, and the PR description explicitly notes documentation has not been
updated and includes a TODO to update the migration docs.

Rule 2: Docs updated for user-facing changes
src/index.ts[145-149]

Agent prompt

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

## Issue description
User-facing API exports (`Connection` / `ConnectionOptions`) were removed, but this PR does not include documentation changes to guide users to `DataSource` / `DataSourceOptions`.
## Issue Context
The PR description explicitly calls out a TODO to update the "migration to v1" documentation, and the docs checklist item is unchecked.
## Fix Focus Areas
- src/index.ts[145-149]

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

Description

This PR removes user-facing exports (Connection/ConnectionOptions) but no documentation updates
are included. Users upgrading may not know how to migrate to DataSource/DataSourceOptions.

Code

src/index.ts[L146-148]

-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"

Evidence

Compliance requires documentation updates for user-facing API/usage changes. The PR removes public
exports in src/index.ts, and the PR description explicitly notes documentation has not been
updated and includes a TODO to update the migration docs.

Rule 2: Docs updated for user-facing changes
src/index.ts[145-149]

Agent prompt

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

## Issue description
User-facing API exports (`Connection` / `ConnectionOptions`) were removed, but this PR does not include documentation changes to guide users to `DataSource` / `DataSourceOptions`.
## Issue Context
The PR description explicitly calls out a TODO to update the "migration to v1" documentation, and the docs checklist item is unchecked.
## Fix Focus Areas
- src/index.ts[145-149]

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

Description

An empty JSDoc block with only an @param tag was added above the local run() helper, adding
noise without improving clarity. This violates the requirement to avoid extra AI-like comments and
keeps the file style unnecessarily verbose.

Code

src/driver/sqlite/SqliteDriver.ts[R156-159]

+        /**
+         *
+         * @param line
+         */

Evidence

PR Compliance ID 4 requires avoiding extra/AI-like comments; the added JSDoc block contains no
description and only an @param tag, making it pure comment noise.

Rule 4: Remove AI-generated noise
src/driver/sqlite/SqliteDriver.ts[155-160]

Agent prompt

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

## Issue description
An empty JSDoc comment block was added above the local `run()` helper in `SqliteDriver`, containing no useful description and only an `@param` tag. This is comment noise and violates the "Remove AI-generated noise" compliance requirement.
## Issue Context
There is already a clear single-line comment explaining the purpose of `run()`, so the empty JSDoc adds verbosity without value.
## Fix Focus Areas
- src/driver/sqlite/SqliteDriver.ts[156-159]

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

Description

This PR removes user-facing exports (Connection/ConnectionOptions) but no documentation updates
are included. Users upgrading may not know how to migrate to DataSource/DataSourceOptions.

Code

src/index.ts[L146-148]

-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"

Evidence

Compliance requires documentation updates for user-facing API/usage changes. The PR removes public
exports in src/index.ts, and the PR description explicitly notes documentation has not been
updated and includes a TODO to update the migration docs.

Rule 2: Docs updated for user-facing changes
src/index.ts[145-149]

Agent prompt

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

## Issue description
User-facing API exports (`Connection` / `ConnectionOptions`) were removed, but this PR does not include documentation changes to guide users to `DataSource` / `DataSourceOptions`.
## Issue Context
The PR description explicitly calls out a TODO to update the "migration to v1" documentation, and the docs checklist item is unchecked.
## Fix Focus Areas
- src/index.ts[145-149]

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

Description

This PR removes user-facing exports (Connection/ConnectionOptions) but no documentation updates
are included. Users upgrading may not know how to migrate to DataSource/DataSourceOptions.

Code

src/index.ts[L146-148]

-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"

Evidence

Compliance requires documentation updates for user-facing API/usage changes. The PR removes public
exports in src/index.ts, and the PR description explicitly notes documentation has not been
updated and includes a TODO to update the migration docs.

Rule 2: Docs updated for user-facing changes
src/index.ts[145-149]

Agent prompt

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

## Issue description
User-facing API exports (`Connection` / `ConnectionOptions`) were removed, but this PR does not include documentation changes to guide users to `DataSource` / `DataSourceOptions`.
## Issue Context
The PR description explicitly calls out a TODO to update the "migration to v1" documentation, and the docs checklist item is unchecked.
## Fix Focus Areas
- src/index.ts[145-149]

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

Description

This PR removes user-facing exports (Connection/ConnectionOptions) but no documentation updates
are included. Users upgrading may not know how to migrate to DataSource/DataSourceOptions.

Code

src/index.ts[L146-148]

-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"

Evidence

Compliance requires documentation updates for user-facing API/usage changes. The PR removes public
exports in src/index.ts, and the PR description explicitly notes documentation has not been
updated and includes a TODO to update the migration docs.

Rule 2: Docs updated for user-facing changes
src/index.ts[145-149]

Agent prompt

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

## Issue description
User-facing API exports (`Connection` / `ConnectionOptions`) were removed, but this PR does not include documentation changes to guide users to `DataSource` / `DataSourceOptions`.
## Issue Context
The PR description explicitly calls out a TODO to update the "migration to v1" documentation, and the docs checklist item is unchecked.
## Fix Focus Areas
- src/index.ts[145-149]

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

Description

After removing DataSource.connect(), some public-facing guidance (JSDoc and an exported error
message) still instructs users to call connect(). Users following these messages will now hit
compile/runtime failures and have a harder time diagnosing initialization issues.

Code

src/data-source/DataSource.ts[L288-297]

-    /**
-     * Performs connection to the database.
-     * This method should be called once on application bootstrap.
-     * This method not necessarily creates database connection (depend on database type),
-     * but it also can setup a connection pool with database to use.
-     * @deprecated use .initialize method instead
-     */
-    async connect(): Promise<this> {
-        return this.initialize()
-    }

Evidence

The PR removes DataSource.connect() (diff pointer), but ConnectionManager.create() still says to
"manually call connect" and NoConnectionForRepositoryError still says "Call connection#connect".
Meanwhile, the replacement is clearly initialize() (used by globals.createConnection), and
DataSource exposes initialize()/destroy() with no connect()/close() in between.

src/connection/ConnectionManager.ts[48-52]
src/error/NoConnectionForRepositoryError.ts[6-12]
src/globals.ts[90-99]
src/data-source/DataSource.ts[279-293]
src/index.ts[145-148]

Agent prompt

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

## Issue description
`DataSource.connect()` was removed, but some public-facing strings/docs still recommend calling `connect()`.
### Issue Context
This PR intentionally removes deprecated `connect/close` in favor of `initialize/destroy`.
### Fix Focus Areas
- src/connection/ConnectionManager.ts[48-52]
- src/error/NoConnectionForRepositoryError.ts[6-12]
### Suggested change
- Replace “call connect method” with “call initialize()” in `ConnectionManager.create()` JSDoc.
- Update `NoConnectionForRepositoryError` message to say “Call dataSource.initialize()” (or “connection.initialize()” if you want to keep legacy wording), since `connect()` no longer exists.

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

Description

this.dataSource.driver.options is cast to any, bypassing type safety and potentially hiding
schema-option typing issues. This conflicts with the requirement to avoid any-casts added/retained
in changed code.

Code

src/cache/DbQueryResultCache.ts[29]

+        const { schema } = this.dataSource.driver.options as any

Evidence

PR Compliance ID 4 disallows any-casts used to bypass types; the modified constructor line
explicitly uses as any when reading schema from driver options.

Rule 4: Remove AI-generated noise
src/cache/DbQueryResultCache.ts[29-29]

Agent prompt

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

## Issue description
`DbQueryResultCache` reads `schema` via `this.dataSource.driver.options as any`, which bypasses type checking.
## Issue Context
The PR compliance checklist disallows `any`-casts used to bypass types in changed code.
## Fix Focus Areas
- src/cache/DbQueryResultCache.ts[28-30]

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

Description

After removing TypeORM’s ConnectionOptions export, the package root still exports a
ConnectionOptions type coming from the MongoDB driver typings, so `import { ConnectionOptions }
from "typeorm"` may still type-check but refer to the wrong type. This undermines the
breaking-change intent and can lead to confusing or incorrect typing during migration to
DataSourceOptions.

Code

src/index.ts[R143-147]

export { ConnectionOptionsReader } from "./connection/ConnectionOptionsReader"
-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"
export { ConnectionManager } from "./connection/ConnectionManager"
export { DataSourceOptions } from "./data-source/DataSourceOptions"
export { Driver } from "./driver/Driver"

Evidence

src/index.ts re-exports everything from the MongoDB typings module, and that module declares an
exported ConnectionOptions interface. The PR diff removes TypeORM’s own ConnectionOptions
export, so the remaining exported ConnectionOptions name at the package root will now resolve to
the MongoDB one instead of failing fast or guiding users to DataSourceOptions.

pr_files_diffs/src_index_ts.patch[6-18]
src/index.ts[128-141]
src/driver/mongodb/typings.ts[2557-2564]

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 root module (`src/index.ts`) still re-exports `ConnectionOptions` from `./driver/mongodb/typings`. After this PR removes TypeORM’s own `ConnectionOptions`, consumers may still be able to import `ConnectionOptions` from `typeorm`, but it will now refer to MongoDB’s driver `ConnectionOptions` instead of failing fast / guiding them to `DataSourceOptions`.
### Issue Context
The PR goal is to remove the deprecated `Connection` / `ConnectionOptions` in favor of `DataSource` / `DataSourceOptions`. Leaving an unrelated `ConnectionOptions` symbol in the root exports undermines that migration.
### Fix Focus Areas
- src/index.ts[128-147]
- src/driver/mongodb/typings.ts[2557-2575]
### Suggested approaches
1) Prefer: remove `export * from "./driver/mongodb/typings"` from the root and expose MongoDB typings via a dedicated subpath/barrel (or `export * as MongoDB from ...`) to prevent name collisions.
2) Alternative: in the MongoDB typings module, rename/alias the exported `ConnectionOptions` type to something explicit (e.g., `MongoConnectionOptions`) and avoid exporting `ConnectionOptions` at the root (this may require changing how typings are generated/committed).
### Acceptance criteria
- `ConnectionOptions` is no longer available as a root export from `typeorm`.
- MongoDB-specific typings remain accessible in a non-colliding way (namespaced or subpath).
- Build/typecheck succeeds.

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

Description

After removing DataSource.connect(), some public-facing guidance (JSDoc and an exported error
message) still instructs users to call connect(). Users following these messages will now hit
compile/runtime failures and have a harder time diagnosing initialization issues.

Code

src/data-source/DataSource.ts[L288-297]

-    /**
-     * Performs connection to the database.
-     * This method should be called once on application bootstrap.
-     * This method not necessarily creates database connection (depend on database type),
-     * but it also can setup a connection pool with database to use.
-     * @deprecated use .initialize method instead
-     */
-    async connect(): Promise<this> {
-        return this.initialize()
-    }

Evidence

The PR removes DataSource.connect() (diff pointer), but ConnectionManager.create() still says to
"manually call connect" and NoConnectionForRepositoryError still says "Call connection#connect".
Meanwhile, the replacement is clearly initialize() (used by globals.createConnection), and
DataSource exposes initialize()/destroy() with no connect()/close() in between.

src/connection/ConnectionManager.ts[48-52]
src/error/NoConnectionForRepositoryError.ts[6-12]
src/globals.ts[90-99]
src/data-source/DataSource.ts[279-293]
src/index.ts[145-148]

Agent prompt

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

## Issue description
`DataSource.connect()` was removed, but some public-facing strings/docs still recommend calling `connect()`.
### Issue Context
This PR intentionally removes deprecated `connect/close` in favor of `initialize/destroy`.
### Fix Focus Areas
- src/connection/ConnectionManager.ts[48-52]
- src/error/NoConnectionForRepositoryError.ts[6-12]
### Suggested change
- Replace “call connect method” with “call initialize()” in `ConnectionManager.create()` JSDoc.
- Update `NoConnectionForRepositoryError` message to say “Call dataSource.initialize()” (or “connection.initialize()” if you want to keep legacy wording), since `connect()` no longer exists.

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

Description

A commented-out Aurora test block still calls connection.connect(), but this PR removes
DataSource.connect() (replaced by DataSource.initialize()). If a contributor uncomments these
tests (as the file suggests for Aurora manual testing), they will fail to compile/run.

Code

test/functional/connection-manager/connection-manager.test.ts[81]

          await connection.connect();

Evidence

The PR explicitly removes the deprecated DataSource.connect() method, but the edited test file
still contains await connection.connect() in the (commented) Aurora test snippets within the same
file/hunks, leaving misleading guidance for manual testing.

pr_files_diffs/src_data-source_DataSource_ts.patch
pr_files_diffs/test_functional_connection-manager_connection-manager_test_ts.patch
test/functional/connection-manager/connection-manager.test.ts[58-83]

Agent prompt

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

## Issue description
A commented-out Aurora test block still uses `DataSource.connect()`, but the method was removed in this PR. If someone uncomments these tests for local/manual Aurora verification, they will immediately fail.
### Issue Context
The PR removes deprecated `DataSource.connect()` in favor of `DataSource.initialize()`.
### Fix Focus Areas
- test/functional/connection-manager/connection-manager.test.ts[58-106]
- src/data-source/DataSource.ts[279-323]

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

Description

After removing DataSource.connect(), some public-facing guidance (JSDoc and an exported error
message) still instructs users to call connect(). Users following these messages will now hit
compile/runtime failures and have a harder time diagnosing initialization issues.

Code

src/data-source/DataSource.ts[L288-297]

-    /**
-     * Performs connection to the database.
-     * This method should be called once on application bootstrap.
-     * This method not necessarily creates database connection (depend on database type),
-     * but it also can setup a connection pool with database to use.
-     * @deprecated use .initialize method instead
-     */
-    async connect(): Promise<this> {
-        return this.initialize()
-    }

Evidence

The PR removes DataSource.connect() (diff pointer), but ConnectionManager.create() still says to
"manually call connect" and NoConnectionForRepositoryError still says "Call connection#connect".
Meanwhile, the replacement is clearly initialize() (used by globals.createConnection), and
DataSource exposes initialize()/destroy() with no connect()/close() in between.

src/connection/ConnectionManager.ts[48-52]
src/error/NoConnectionForRepositoryError.ts[6-12]
src/globals.ts[90-99]
src/data-source/DataSource.ts[279-293]
src/index.ts[145-148]

Agent prompt

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

## Issue description
`DataSource.connect()` was removed, but some public-facing strings/docs still recommend calling `connect()`.
### Issue Context
This PR intentionally removes deprecated `connect/close` in favor of `initialize/destroy`.
### Fix Focus Areas
- src/connection/ConnectionManager.ts[48-52]
- src/error/NoConnectionForRepositoryError.ts[6-12]
### Suggested change
- Replace “call connect method” with “call initialize()” in `ConnectionManager.create()` JSDoc.
- Update `NoConnectionForRepositoryError` message to say “Call dataSource.initialize()” (or “connection.initialize()” if you want to keep legacy wording), since `connect()` no longer exists.

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

Description

this.dataSource.driver.options is cast to any, bypassing type safety and potentially hiding
schema-option typing issues. This conflicts with the requirement to avoid any-casts added/retained
in changed code.

Code

src/cache/DbQueryResultCache.ts[29]

+        const { schema } = this.dataSource.driver.options as any

Evidence

PR Compliance ID 4 disallows any-casts used to bypass types; the modified constructor line
explicitly uses as any when reading schema from driver options.

Rule 4: Remove AI-generated noise
src/cache/DbQueryResultCache.ts[29-29]

Agent prompt

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

## Issue description
`DbQueryResultCache` reads `schema` via `this.dataSource.driver.options as any`, which bypasses type checking.
## Issue Context
The PR compliance checklist disallows `any`-casts used to bypass types in changed code.
## Fix Focus Areas
- src/cache/DbQueryResultCache.ts[28-30]

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

Description

After removing TypeORM’s ConnectionOptions export, the package root still exports a
ConnectionOptions type coming from the MongoDB driver typings, so `import { ConnectionOptions }
from "typeorm"` may still type-check but refer to the wrong type. This undermines the
breaking-change intent and can lead to confusing or incorrect typing during migration to
DataSourceOptions.

Code

src/index.ts[R143-147]

export { ConnectionOptionsReader } from "./connection/ConnectionOptionsReader"
-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"
export { ConnectionManager } from "./connection/ConnectionManager"
export { DataSourceOptions } from "./data-source/DataSourceOptions"
export { Driver } from "./driver/Driver"

Evidence

src/index.ts re-exports everything from the MongoDB typings module, and that module declares an
exported ConnectionOptions interface. The PR diff removes TypeORM’s own ConnectionOptions
export, so the remaining exported ConnectionOptions name at the package root will now resolve to
the MongoDB one instead of failing fast or guiding users to DataSourceOptions.

pr_files_diffs/src_index_ts.patch[6-18]
src/index.ts[128-141]
src/driver/mongodb/typings.ts[2557-2564]

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 root module (`src/index.ts`) still re-exports `ConnectionOptions` from `./driver/mongodb/typings`. After this PR removes TypeORM’s own `ConnectionOptions`, consumers may still be able to import `ConnectionOptions` from `typeorm`, but it will now refer to MongoDB’s driver `ConnectionOptions` instead of failing fast / guiding them to `DataSourceOptions`.
### Issue Context
The PR goal is to remove the deprecated `Connection` / `ConnectionOptions` in favor of `DataSource` / `DataSourceOptions`. Leaving an unrelated `ConnectionOptions` symbol in the root exports undermines that migration.
### Fix Focus Areas
- src/index.ts[128-147]
- src/driver/mongodb/typings.ts[2557-2575]
### Suggested approaches
1) Prefer: remove `export * from "./driver/mongodb/typings"` from the root and expose MongoDB typings via a dedicated subpath/barrel (or `export * as MongoDB from ...`) to prevent name collisions.
2) Alternative: in the MongoDB typings module, rename/alias the exported `ConnectionOptions` type to something explicit (e.g., `MongoConnectionOptions`) and avoid exporting `ConnectionOptions` at the root (this may require changing how typings are generated/committed).
### Acceptance criteria
- `ConnectionOptions` is no longer available as a root export from `typeorm`.
- MongoDB-specific typings remain accessible in a non-colliding way (namespaced or subpath).
- Build/typecheck succeeds.

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

Description

After removing DataSource.connect(), some public-facing guidance (JSDoc and an exported error
message) still instructs users to call connect(). Users following these messages will now hit
compile/runtime failures and have a harder time diagnosing initialization issues.

Code

src/data-source/DataSource.ts[L288-297]

-    /**
-     * Performs connection to the database.
-     * This method should be called once on application bootstrap.
-     * This method not necessarily creates database connection (depend on database type),
-     * but it also can setup a connection pool with database to use.
-     * @deprecated use .initialize method instead
-     */
-    async connect(): Promise<this> {
-        return this.initialize()
-    }

Evidence

The PR removes DataSource.connect() (diff pointer), but ConnectionManager.create() still says to
"manually call connect" and NoConnectionForRepositoryError still says "Call connection#connect".
Meanwhile, the replacement is clearly initialize() (used by globals.createConnection), and
DataSource exposes initialize()/destroy() with no connect()/close() in between.

src/connection/ConnectionManager.ts[48-52]
src/error/NoConnectionForRepositoryError.ts[6-12]
src/globals.ts[90-99]
src/data-source/DataSource.ts[279-293]
src/index.ts[145-148]
...

Description

This PR removes user-facing exports (Connection/ConnectionOptions) but no documentation updates
are included. Users upgrading may not know how to migrate to DataSource/DataSourceOptions.

Code

src/index.ts[L146-148]

-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"

Evidence

Compliance requires documentation updates for user-facing API/usage changes. The PR removes public
exports in src/index.ts, and the PR description explicitly notes documentation has not been
updated and includes a TODO to update the migration docs.

Rule 2: Docs updated for user-facing changes
src/index.ts[145-149]

Agent prompt

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

## Issue description
User-facing API exports (`Connection` / `ConnectionOptions`) were removed, but this PR does not include documentation changes to guide users to `DataSource` / `DataSourceOptions`.
## Issue Context
The PR description explicitly calls out a TODO to update the "migration to v1" documentation, and the docs checklist item is unchecked.
## Fix Focus Areas
- src/index.ts[145-149]

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

Description

After removing TypeORM’s ConnectionOptions export, the package root still exports a
ConnectionOptions type coming from the MongoDB driver typings, so `import { ConnectionOptions }
from "typeorm"` may still type-check but refer to the wrong type. This undermines the
breaking-change intent and can lead to confusing or incorrect typing during migration to
DataSourceOptions.

Code

src/index.ts[R143-147]

export { ConnectionOptionsReader } from "./connection/ConnectionOptionsReader"
-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"
export { ConnectionManager } from "./connection/ConnectionManager"
export { DataSourceOptions } from "./data-source/DataSourceOptions"
export { Driver } from "./driver/Driver"

Evidence

src/index.ts re-exports everything from the MongoDB typings module, and that module declares an
exported ConnectionOptions interface. The PR diff removes TypeORM’s own ConnectionOptions
export, so the remaining exported ConnectionOptions name at the package root will now resolve to
the MongoDB one instead of failing fast or guiding users to DataSourceOptions.

pr_files_diffs/src_index_ts.patch[6-18]
src/index.ts[128-141]
src/driver/mongodb/typings.ts[2557-2564]

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 root module (`src/index.ts`) still re-exports `ConnectionOptions` from `./driver/mongodb/typings`. After this PR removes TypeORM’s own `ConnectionOptions`, consumers may still be able to import `ConnectionOptions` from `typeorm`, but it will now refer to MongoDB’s driver `ConnectionOptions` instead of failing fast / guiding them to `DataSourceOptions`.
### Issue Context
The PR goal is to remove the deprecated `Connection` / `ConnectionOptions` in favor of `DataSource` / `DataSourceOptions`. Leaving an unrelated `ConnectionOptions` symbol in the root exports undermines that migration.
### Fix Focus Areas
- src/index.ts[128-147]
- src/driver/mongodb/typings.ts[2557-2575]
### Suggested approaches
1) Prefer: remove `export * from "./driver/mongodb/typings"` from the root and expose MongoDB typings via a dedicated subpath/barrel (or `export * as MongoDB from ...`) to prevent name collisions.
2) Alternative: in the MongoDB typings module, rename/alias the exported `ConnectionOptions` type to something explicit (e.g., `MongoConnectionOptions`) and avoid exporting `ConnectionOptions` at the root (this may require changing how typings are generated/committed).
### Acceptance criteria
- `ConnectionOptions` is no longer available as a root export from `typeorm`.
- MongoDB-specific typings remain accessible in a non-colliding way (namespaced or subpath).
- Build/typecheck succeeds.

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

Description

After removing DataSource.connect(), some public-facing guidance (JSDoc and an exported error
message) still instructs users to call connect(). Users following these messages will now hit
compile/runtime failures and have a harder time diagnosing initialization issues.

Code

src/data-source/DataSource.ts[L288-297]

-    /**
-     * Performs connection to the database.
-     * This method should be called once on application bootstrap.
-     * This method not necessarily creates database connection (depend on database type),
-     * but it also can setup a connection pool with database to use.
-     * @deprecated use .initialize method instead
-     */
-    async connect(): Promise<this> {
-        return this.initialize()
-    }

Evidence

The PR removes DataSource.connect() (diff pointer), but ConnectionManager.create() still says to
"manually call connect" and NoConnectionForRepositoryError still says "Call connection#connect".
Meanwhile, the replacement is clearly initialize() (used by globals.createConnection), and
DataSource exposes initialize()/destroy() with no connect()/close() in between.

src/connection/ConnectionManager.ts[48-52]
src/error/NoConnectionForRepositoryError.ts[6-12]
src/globals.ts[90-99]
src/data-source/DataSource.ts[279-293]
src/index.ts[145-148]

Agent prompt

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

## Issue description
`DataSource.connect()` was removed, but some public-facing strings/docs still recommend calling `connect()`.
### Issue Context
This PR intentionally removes deprecated `connect/close` in favor of `initialize/destroy`.
### Fix Focus Areas
- src/connection/ConnectionManager.ts[48-52]
- src/error/NoConnectionForRepositoryError.ts[6-12]
### Suggested change
- Replace “call connect method” with “call initialize()” in `ConnectionManager.create()` JSDoc.
- Update `NoConnectionForRepositoryError` message to say “Call dataSource.initialize()” (or “connection.initialize()” if you want to keep legacy wording), since `connect()` no longer exists.

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

Description

this.dataSource.driver.options is cast to any, bypassing type safety and potentially hiding
schema-option typing issues. This conflicts with the requirement to avoid any-casts added/retained
in changed code.

Code

src/cache/DbQueryResultCache.ts[29]

+        const { schema } = this.dataSource.driver.options as any

Evidence

PR Compliance ID 4 disallows any-casts used to bypass types; the modified constructor line
explicitly uses as any when reading schema from driver options.

Rule 4: Remove AI-generated noise
src/cache/DbQueryResultCache.ts[29-29]

Agent prompt

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

## Issue description
`DbQueryResultCache` reads `schema` via `this.dataSource.driver.options as any`, which bypasses type checking.
## Issue Context
The PR compliance checklist disallows `any`-casts used to bypass types in changed code.
## Fix Focus Areas
- src/cache/DbQueryResultCache.ts[28-30]

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

Description

After removing TypeORM’s ConnectionOptions export, the package root still exports a
ConnectionOptions type coming from the MongoDB driver typings, so `import { ConnectionOptions }
from "typeorm"` may still type-check but refer to the wrong type. This undermines the
breaking-change intent and can lead to confusing or incorrect typing during migration to
DataSourceOptions.

Code

src/index.ts[R143-147]

export { ConnectionOptionsReader } from "./connection/ConnectionOptionsReader"
-export { ConnectionOptions } from "./connection/ConnectionOptions"
export { DataSource } from "./data-source/DataSource"
-export { Connection } from "./connection/Connection"
export { ConnectionManager } from "./connection/ConnectionManager"
export { DataSourceOptions } from "./data-source/DataSourceOptions"
export { Driver } from "./driver/Driver"

Evidence

src/index.ts re-exports everything from the MongoDB typings module, and that module declares an
exported ConnectionOptions interface. The PR diff removes TypeORM’s own ConnectionOptions
export, so the remaining exported ConnectionOptions name at the package root will now resolve to
the MongoDB one instead of failing fast or guiding users to DataSourceOptions.

pr_files_diffs/src_index_ts.patch[6-18]
src/index.ts[128-141]
src/driver/mongodb/typings.ts[2557-2564]

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 root module (`src/index.ts`) still re-exports `ConnectionOptions` from `./driver/mongodb/typings`. After this PR removes TypeORM’s own `ConnectionOptions`, consumers may still be able to import `ConnectionOptions` from `typeorm`, but it will now refer to MongoDB’s driver `ConnectionOptions` instead of failing fast / guiding them to `DataSourceOptions`.
### Issue Context
The PR goal is to remove the deprecated `Connection` / `ConnectionOptions` in favor of `DataSource` / `DataSourceOptions`. Leaving an unrelated `ConnectionOptions` symbol in the root exports undermines that migration.
### Fix Focus Areas
- src/index.ts[128-147]
- src/driver/mongodb/typings.ts[2557-2575]
### Suggested approaches
1) Prefer: remove `export * from "./driver/mongodb/typings"` from the root and expose MongoDB typings via a dedicated subpath/barrel (or `export * as MongoDB from ...`) to prevent name collisions.
2) Alternative: in the MongoDB typings module, rename/alias the exported `ConnectionOptions` type to something explicit (e.g., `MongoConnectionOptions`) and avoid exporting `ConnectionOptions` at the root (this may require changing how typings are generated/committed).
### Acceptance criteria
- `ConnectionOptions` is no longer available as a root export from `typeorm`.
- MongoDB-specific typings remain accessible in a non-colliding way (namespaced or subpath).
- Build/typecheck succeeds.

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

Description

After removing DataSource.connect(), some public-facing guidance (JSDoc and an exported error
message) still instructs users to call connect(). Users following these messages will now hit
compile/runtime failures and have a harder time diagnosing initialization issues.

Code

src/data-source/DataSource.ts[L288-297]

-    /**
-     * Performs connection to the database.
-     * This method should be called once on application bootstrap.
-     * This method not necessarily creates database connection (depend on database type),
-     * but it also can setup a connection pool with database to use.
-     * @deprecated use .initialize method instead
-     */
-    async connect(): Promise<this> {
-        return this.initialize()
-    }

Evidence

The PR removes DataSource.connect() (diff pointer), but ConnectionManager.create() still says to
"manually call connect" and NoConnectionForRepositoryError still says "Call connection#connect".
Meanwhile, the replacement is clearly initialize() (used by globals.createConnection), and
DataSource exposes initialize()/destroy() with no connect()/close() in between.

src/connection/ConnectionManager.ts[48-52]
src/error/NoConnectionForRepositoryError.ts[6-12]
src/globals.ts[90-99]
src/data-source/DataSource.ts[279-293]
src/index.ts[145-148]

Agent prompt

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

## Issue description
`DataSource.connect()` was removed, but some public-facing strings/docs still recommend calling `connect()`.
### Issue Context
This PR intentionally removes deprecated `connect/close` in favor of `initialize/destroy`.
### Fix Focus Areas
- src/connection/ConnectionManager.ts[48-52]
- src/error/NoConnectionForRepositoryError.ts[6-12]
### Suggested change
- Replace “call connect method” with “call initialize()” in `ConnectionManager.create()` JSDoc.
- Update `NoConnectionForRepositoryError` message to say “Call dataSource.initialize()” (or “connection.initialize()” if you want to keep legacy wording), since `connect()` no longer exists.

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