refactor(ConnectionOptionsReader)!: remove deprecated DataSource.name and simplify API by pkuczynski · Pull Request #12136 · typeorm/typeorm

pkuczynski · 2026-03-08T10:14:18Z

Remove the deprecated name property from DataSource and BaseDataSourceOptions. Rename ConnectionOptionsReader.all() to get() and remove the old get(name) and has(name) methods that relied on named connections.

Part of #11603.

cloudflare-workers-and-pages · 2026-03-08T10:14:25Z

Deploying typeorm with Cloudflare Pages

Latest commit:	`6f2bd51`
Status:	✅ Deploy successful!
Preview URL:	https://a65032ed.typeorm.pages.dev
Branch Preview URL:	https://refactor-remove-deprecated-d.typeorm.pages.dev

View logs

qodo-free-for-open-source-projects · 2026-03-08T10:14:41Z

Review Summary by Qodo

Remove deprecated DataSource.name and simplify ConnectionOptionsReader API

✨ Enhancement

Walkthroughs

Description

• Remove deprecated name property from DataSource and BaseDataSourceOptions
• Rename ConnectionOptionsReader.all() to get() and remove named connection methods
• Update error classes to remove connection name parameter
• Replace dataSource.name references with dataSource.options.type in tests
• Simplify configuration files by removing name field from all examples

Diagram

flowchart LR
  A["DataSource with name property"] -->|Remove deprecated name| B["DataSource without name"]
  C["ConnectionOptionsReader.all()"] -->|Rename to get| D["ConnectionOptionsReader.get()"]
  E["get(name) and has(name) methods"] -->|Remove| F["Simplified API"]
  G["Error classes with connectionName"] -->|Remove parameter| H["Generic error messages"]

File Changes

1. src/data-source/BaseDataSourceOptions.ts ✨ Enhancement +0/-7

Remove deprecated name property from interface

src/data-source/BaseDataSourceOptions.ts

2. src/data-source/DataSource.ts ✨ Enhancement +6/-18

Remove name property and update error handling

src/data-source/DataSource.ts

3. src/connection/ConnectionOptionsReader.ts ✨ Enhancement +1/-35

Rename all() to get() and remove named methods

src/connection/ConnectionOptionsReader.ts

View more (30)

4. src/error/CannotConnectAlreadyConnectedError.ts ✨ Enhancement +2/-2

Remove connectionName parameter from constructor

src/error/CannotConnectAlreadyConnectedError.ts

5. src/error/CannotExecuteNotConnectedError.ts ✨ Enhancement +2/-2

Remove connectionName parameter from constructor

src/error/CannotExecuteNotConnectedError.ts

6. sample/sample1-simple-entity/app.ts ⚙️ Configuration changes +0/-1

Remove name field from DataSourceOptions

sample/sample1-simple-entity/app.ts

7. sample/sample32-migrations/app.ts ⚙️ Configuration changes +0/-1

Remove name field from DataSourceOptions

sample/sample32-migrations/app.ts

8. test/functional/columns/value-transformer/value-transformer.test.ts 🧪 Tests +3/-3

Replace dataSource.name with dataSource.options.type

test/functional/columns/value-transformer/value-transformer.test.ts

9. test/functional/commands/migration-create.test.ts 🧪 Tests +25/-25

Update to use new get() API returning array

test/functional/commands/migration-create.test.ts

10. test/functional/commands/migration-generate.test.ts 🧪 Tests +22/-22

Update to use new get() API returning array

test/functional/commands/migration-generate.test.ts

11. test/functional/data-source/data-source.test.ts 🧪 Tests +0/-7

Remove name field from test configurations

test/functional/data-source/data-source.test.ts

12. test/functional/query-builder/count/query-builder-count.test.ts 🧪 Tests +2/-2

Replace dataSource.name with dataSource.options.type

test/functional/query-builder/count/query-builder-count.test.ts

13. test/functional/query-runner/drop-column.test.ts 🧪 Tests +2/-2

Replace dataSource.name with dataSource.options.type

test/functional/query-runner/drop-column.test.ts

14. test/functional/repository/basic-methods/repository-basic-methods.test.ts 🧪 Tests +1/-1

Replace dataSource.name with dataSource.options.type

test/functional/repository/basic-methods/repository-basic-methods.test.ts

15. test/functional/schema-builder/change-column.test.ts 🧪 Tests +3/-3

Replace dataSource.name with dataSource.options.type

test/functional/schema-builder/change-column.test.ts

16. test/github-issues/2096/issue-2096.test.ts 🧪 Tests +1/-2

Remove name field and update config lookup

test/github-issues/2096/issue-2096.test.ts

17. test/github-issues/4415/issue-4415.test.ts 🧪 Tests +17/-17

Update to use new get() API returning array

test/github-issues/4415/issue-4415.test.ts

18. test/github-issues/5119/issue-5119.test.ts 🧪 Tests +0/-1

Remove name field from test configuration

test/github-issues/5119/issue-5119.test.ts

19. test/github-issues/6115/issue-6115.test.ts 🧪 Tests +0/-1

Remove name field from test configuration

test/github-issues/6115/issue-6115.test.ts

20. test/github-issues/6284/issue-6284.test.ts 🧪 Tests +1/-1

Update to use new get() method

test/github-issues/6284/issue-6284.test.ts

21. test/github-issues/6714/issue-6714.test.ts 🧪 Tests +0/-1

Remove name field from test configuration

test/github-issues/6714/issue-6714.test.ts

22. test/github-issues/799/issue-799.test.ts 🧪 Tests +0/-1

Remove name field from DataSource options

test/github-issues/799/issue-799.test.ts

23. test/github-issues/8556/issue-8556.test.ts 🧪 Tests +0/-2

Remove name field and generateRandomText usage

test/github-issues/8556/issue-8556.test.ts

24. test/github-issues/8627/issue-8627.test.ts 🧪 Tests +0/-2

Remove name field and generateRandomText usage

test/github-issues/8627/issue-8627.test.ts

25. test/unit/connection-options-reader/configs/class-entities.ts ⚙️ Configuration changes +0/-1

Remove name field from config

test/unit/connection-options-reader/configs/class-entities.ts

26. test/unit/connection-options-reader/configs/test-path-config-async.ts ⚙️ Configuration changes +0/-1

Remove name field from config

test/unit/connection-options-reader/configs/test-path-config-async.ts

27. test/unit/connection-options-reader/configs/test-path-config-esm.ts ⚙️ Configuration changes +4/-7

Remove name field and convert to single config

test/unit/connection-options-reader/configs/test-path-config-esm.ts

28. test/unit/connection-options-reader/configs/test-path-config.ts ⚙️ Configuration changes +4/-7

Remove name field and convert to single config

test/unit/connection-options-reader/configs/test-path-config.ts

29. test/unit/connection-options-reader/connection-options-reader.test.ts 🧪 Tests +12/-12

Update tests to use new get() API

test/unit/connection-options-reader/connection-options-reader.test.ts

30. test/utils/test-utils.ts 🧪 Tests +0/-11

Remove name option from TestingOptions interface

test/utils/test-utils.ts

31. docs/docs/guides/8-migration-v1.md 📝 Documentation +19/-0

Add migration guide for name property removal

docs/docs/guides/8-migration-v1.md

32. ormconfig.sample.json ⚙️ Configuration changes +0/-13

Remove name field from all database configurations

ormconfig.sample.json

33. src/platform/BrowserConnectionOptionsReaderDummy.template ✨ Enhancement +0/-8

Remove all() and has() methods from dummy class

src/platform/BrowserConnectionOptionsReaderDummy.template

pkg-pr-new · 2026-03-08T10:15:09Z

typeorm-sql-js-example

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

commit: 6f2bd51

qodo-free-for-open-source-projects · 2026-03-08T10:20:59Z

Code Review by Qodo

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

1. Config paths not applied 🐞 Bug ✓ Correctness

Description

ConnectionOptionsReader.normalizeConnectionOptions computes absolute
entities/subscribers/migrations paths but assigns them to the options array object instead of
the per-DataSourceOptions entry, so consumers still receive unnormalized relative globs and class
discovery can fail when the working directory differs from the config root.

Code

src/connection/ConnectionOptionsReader.ts[R40-43]

+    async get(): Promise<DataSourceOptions[]> {
     const options = await this.load()
     if (!options)
         throw new TypeORMError(

Evidence

After this PR, ConnectionOptionsReader.get() is the sole public API for reading all configs, and
it returns the result of load()/normalizeConnectionOptions(). However,
normalizeConnectionOptions() uses Object.assign(connectionOptions, …) (where connectionOptions
is an array) rather than mutating the current options element, so the normalized arrays are not
applied to each returned config. Downstream, entity/migration/subscriber directories are consumed
as-is and globbed without resolving relative paths, making relative patterns depend on
process.cwd() rather than the config’s root/base directory.

src/connection/ConnectionOptionsReader.ts[37-48]
src/connection/ConnectionOptionsReader.ts[140-187]
src/connection/ConnectionMetadataBuilder.ts[83-99]
src/util/DirectoryExportedClassesLoader.ts[44-46]
src/platform/PlatformTools.ts[156-161]

Agent prompt

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

## Issue description
`ConnectionOptionsReader.normalizeConnectionOptions()` computes normalized `entities` / `subscribers` / `migrations` arrays (prefixing `baseDirectory`), but it assigns them to the `connectionOptions` array object rather than to the current `options` element.
As a result, callers of `ConnectionOptionsReader.get()` receive configs whose `entities`/`subscribers`/`migrations` remain unnormalized relative globs, which can break class discovery when `process.cwd()` is not the same as the config root.
### Issue Context
The normalization logic already correctly mutates `options.database` for sqlite, so this appears to be an inconsistent assignment target for the list-based fields.
### Fix Focus Areas
- src/connection/ConnectionOptionsReader.ts[146-187]
### Suggested change
- Replace:
- `Object.assign(connectionOptions, { entities })`
- `Object.assign(connectionOptions, { subscribers })`
- `Object.assign(connectionOptions, { migrations })`
- With per-option mutation, e.g.:
- `Object.assign(options, { entities })` (or `options.entities = entities`)
- `Object.assign(options, { subscribers })`
- `Object.assign(options, { migrations })`
Add/adjust a unit test where `ConnectionOptionsReader` is constructed with `root: &amp;amp;amp;lt;non-cwd&amp;amp;amp;gt;` and config uses relative `entities` glob strings, asserting the returned option’s `entities` entries are prefixed with that root.

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

2. Config paths not applied 🐞 Bug ✓ Correctness

Description

ConnectionOptionsReader.normalizeConnectionOptions computes absolute
entities/subscribers/migrations paths but assigns them to the options array object instead of
the per-DataSourceOptions entry, so consumers still receive unnormalized relative globs and class
discovery can fail when the working directory differs from the config root.

Code

src/connection/ConnectionOptionsReader.ts[R40-43]

+    async get(): Promise<DataSourceOptions[]> {
      const options = await this.load()
      if (!options)
          throw new TypeORMError(

Evidence

After this PR, ConnectionOptionsReader.get() is the sole public API for reading all configs, and
it returns the result of load()/normalizeConnectionOptions(). However,
normalizeConnectionOptions() uses Object.assign(connectionOptions, …) (where connectionOptions
is an array) rather than mutating the current options element, so the normalized arrays are not
applied to each returned config. Downstream, entity/migration/subscriber directories are consumed
as-is and globbed without resolving relative paths, making relative patterns depend on
process.cwd() rather than the config’s root/base directory.

src/connection/ConnectionOptionsReader.ts[37-48]
src/connection/ConnectionOptionsReader.ts[140-187]
src/connection/ConnectionMetadataBuilder.ts[83-99]
src/util/DirectoryExportedClassesLoader.ts[44-46]
src/platform/PlatformTools.ts[156-161]

Agent prompt

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

## Issue description
`ConnectionOptionsReader.normalizeConnectionOptions()` computes normalized `entities` / `subscribers` / `migrations` arrays (prefixing `baseDirectory`), but it assigns them to the `connectionOptions` array object rather than to the current `options` element.
As a result, callers of `ConnectionOptionsReader.get()` receive configs whose `entities`/`subscribers`/`migrations` remain unnormalized relative globs, which can break class discovery when `process.cwd()` is not the same as the config root.
### Issue Context
The normalization logic already correctly mutates `options.database` for sqlite, so this appears to be an inconsistent assignment target for the list-based fields.
### Fix Focus Areas
- src/connection/ConnectionOptionsReader.ts[146-187]
### Suggested change
- Replace:
- `Object.assign(connectionOptions, { entities })`
- `Object.assign(connectionOptions, { subscribers })`
- `Object.assign(connectionOptions, { migrations })`
- With per-option mutation, e.g.:
- `Object.assign(options, { entities })` (or `options.entities = entities`)
- `Object.assign(options, { subscribers })`
- `Object.assign(options, { migrations })`
Add/adjust a unit test where `ConnectionOptionsReader` is constructed with `root: &amp;amp;lt;non-cwd&amp;amp;gt;` and config uses relative `entities` glob strings, asserting the returned option’s `entities` entries are prefixed with that root.

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

3. Config paths not applied 🐞 Bug ✓ Correctness

Description

ConnectionOptionsReader.normalizeConnectionOptions computes absolute
entities/subscribers/migrations paths but assigns them to the options array object instead of
the per-DataSourceOptions entry, so consumers still receive unnormalized relative globs and class
discovery can fail when the working directory differs from the config root.

Code

src/connection/ConnectionOptionsReader.ts[R40-43]

+    async get(): Promise<DataSourceOptions[]> {
       const options = await this.load()
       if (!options)
           throw new TypeORMError(

Evidence

After this PR, ConnectionOptionsReader.get() is the sole public API for reading all configs, and
it returns the result of load()/normalizeConnectionOptions(). However,
normalizeConnectionOptions() uses Object.assign(connectionOptions, …) (where connectionOptions
is an array) rather than mutating the current options element, so the normalized arrays are not
applied to each returned config. Downstream, entity/migration/subscriber directories are consumed
as-is and globbed without resolving relative paths, making relative patterns depend on
process.cwd() rather than the config’s root/base directory.

src/connection/ConnectionOptionsReader.ts[37-48]
src/connection/ConnectionOptionsReader.ts[140-187]
src/connection/ConnectionMetadataBuilder.ts[83-99]
src/util/DirectoryExportedClassesLoader.ts[44-46]
src/platform/PlatformTools.ts[156-161]

Agent prompt

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

## Issue description
`ConnectionOptionsReader.normalizeConnectionOptions()` computes normalized `entities` / `subscribers` / `migrations` arrays (prefixing `baseDirectory`), but it assigns them to the `connectionOptions` array object rather than to the current `options` element.
As a result, callers of `ConnectionOptionsReader.get()` receive configs whose `entities`/`subscribers`/`migrations` remain unnormalized relative globs, which can break class discovery when `process.cwd()` is not the same as the config root.
### Issue Context
The normalization logic already correctly mutates `options.database` for sqlite, so this appears to be an inconsistent assignment target for the list-based fields.
### Fix Focus Areas
- src/connection/ConnectionOptionsReader.ts[146-187]
### Suggested change
- Replace:
- `Object.assign(connectionOptions, { entities })`
- `Object.assign(connectionOptions, { subscribers })`
- `Object.assign(connectionOptions, { migrations })`
- With per-option mutation, e.g.:
- `Object.assign(options, { entities })` (or `options.entities = entities`)
- `Object.assign(options, { subscribers })`
- `Object.assign(options, { migrations })`
Add/adjust a unit test where `ConnectionOptionsReader` is constructed with `root: &amp;lt;non-cwd&amp;gt;` and config uses relative `entities` glob strings, asserting the returned option’s `entities` entries are prefixed with that root.

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

View more (1)

4. Config paths not applied 🐞 Bug ✓ Correctness

Description

ConnectionOptionsReader.normalizeConnectionOptions computes absolute
entities/subscribers/migrations paths but assigns them to the options array object instead of
the per-DataSourceOptions entry, so consumers still receive unnormalized relative globs and class
discovery can fail when the working directory differs from the config root.

Code

src/connection/ConnectionOptionsReader.ts[R40-43]

+    async get(): Promise<DataSourceOptions[]> {
      const options = await this.load()
      if (!options)
          throw new TypeORMError(

Evidence

After this PR, ConnectionOptionsReader.get() is the sole public API for reading all configs, and
it returns the result of load()/normalizeConnectionOptions(). However,
normalizeConnectionOptions() uses Object.assign(connectionOptions, …) (where connectionOptions
is an array) rather than mutating the current options element, so the normalized arrays are not
applied to each returned config. Downstream, entity/migration/subscriber directories are consumed
as-is and globbed without resolving relative paths, making relative patterns depend on
process.cwd() rather than the config’s root/base directory.

src/connection/ConnectionOptionsReader.ts[37-48]
src/connection/ConnectionOptionsReader.ts[140-187]
src/connection/ConnectionMetadataBuilder.ts[83-99]
src/util/DirectoryExportedClassesLoader.ts[44-46]
src/platform/PlatformTools.ts[156-161]

Agent prompt

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

## Issue description
`ConnectionOptionsReader.normalizeConnectionOptions()` computes normalized `entities` / `subscribers` / `migrations` arrays (prefixing `baseDirectory`), but it assigns them to the `connectionOptions` array object rather than to the current `options` element.
As a result, callers of `ConnectionOptionsReader.get()` receive configs whose `entities`/`subscribers`/`migrations` remain unnormalized relative globs, which can break class discovery when `process.cwd()` is not the same as the config root.
### Issue Context
The normalization logic already correctly mutates `options.database` for sqlite, so this appears to be an inconsistent assignment target for the list-based fields.
### Fix Focus Areas
- src/connection/ConnectionOptionsReader.ts[146-187]
### Suggested change
- Replace:
- `Object.assign(connectionOptions, { entities })`
- `Object.assign(connectionOptions, { subscribers })`
- `Object.assign(connectionOptions, { migrations })`
- With per-option mutation, e.g.:
- `Object.assign(options, { entities })` (or `options.entities = entities`)
- `Object.assign(options, { subscribers })`
- `Object.assign(options, { migrations })`
Add/adjust a unit test where `ConnectionOptionsReader` is constructed with `root: &amp;amp;lt;non-cwd&amp;amp;gt;` and config uses relative `entities` glob strings, asserting the returned option’s `entities` entries are prefixed with that root.

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

5. Reader.get arg not rejected 🐞 Bug ⛯ Reliability ⭐ New

Description

ConnectionOptionsReader.get() no longer accepts a connection name but also does not validate
unexpected arguments, so legacy JS/any-typed callers can still pass a name and receive the full
options array, leading to wrong config selection or downstream runtime type errors. This is
especially likely during upgrades because get(name)/has(name) were removed and all() was renamed to
get().

Code

src/connection/ConnectionOptionsReader.ts[R40-43]

+    async get(): Promise<DataSourceOptions[]> {
        const options = await this.load()
        if (!options)
            throw new TypeORMError(

Evidence

The new get() implementation accepts no parameters and simply returns the loaded options array
without guarding against legacy calling patterns; the migration guide explicitly states
get(name)/has(name) were removed and all() renamed to get(), increasing the chance of accidental
misuse during upgrades.

src/connection/ConnectionOptionsReader.ts[37-48]
docs/docs/guides/8-migration-v1.md[402-417]

Agent prompt

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

### Issue description
`ConnectionOptionsReader.get()` is now the only public method, but it does not guard against callers still passing a legacy `name` argument. In JS/any-typed usage this can lead to returning an array where a single options object was expected.

### Issue Context
The migration guide documents removal of `get(name)`/`has(name)` and rename of `all()` -&gt; `get()`. Adding a runtime arity check provides a fast, actionable failure mode during upgrades.

### Fix Focus Areas
- src/connection/ConnectionOptionsReader.ts[37-48]

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

6. Ambiguous config selection 🐞 Bug ✓ Correctness

Description

The migration guide demonstrates selecting a specific ormconfig entry by o.type === "postgres",
but type is not guaranteed to be unique when multiple DataSources share the same driver. This can
lead users to inadvertently pick the wrong configuration and run operations (e.g., migrations)
against the wrong database/schema.

Code

docs/docs/guides/8-migration-v1.md[R291-294]

+// when you need a specific config from multiple data sources
+const allOptions = await reader.get()
+const postgresOptions = allOptions.find((o) => o.type === "postgres")
+```

Evidence
The guide’s example selects a config by driver type only, but the repo itself contains scenarios
with multiple Postgres DataSources differentiated by schema, showing that type alone is
insufficient to identify a single config.
docs/docs/guides/8-migration-v1.md[285-294]
test/functional/data-source/data-source.test.ts[298-314]

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 migration guide example suggests selecting a specific config from multiple ormconfig entries using only `o.type === &amp;amp;quot;postgres&amp;amp;quot;`, but `type` is not a unique identifier if multiple DataSources share the same driver.
## Issue Context
With named connections removed, docs should not imply that `type` is a safe replacement for `name` as a unique key.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[285-294]

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

7. Ambiguous config selection 🐞 Bug ✓ Correctness

Description

The migration guide demonstrates selecting a specific ormconfig entry by o.type === "postgres",
but type is not guaranteed to be unique when multiple DataSources share the same driver. This can
lead users to inadvertently pick the wrong configuration and run operations (e.g., migrations)
against the wrong database/schema.

Code

docs/docs/guides/8-migration-v1.md[R291-294]

+// when you need a specific config from multiple data sources
+const allOptions = await reader.get()
+const postgresOptions = allOptions.find((o) => o.type === "postgres")
+```

Evidence
The guide’s example selects a config by driver type only, but the repo itself contains scenarios
with multiple Postgres DataSources differentiated by schema, showing that type alone is
insufficient to identify a single config.
docs/docs/guides/8-migration-v1.md[285-294]
test/functional/data-source/data-source.test.ts[298-314]

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 migration guide example suggests selecting a specific config from multiple ormconfig entries using only `o.type === &amp;amp;quot;postgres&amp;amp;quot;`, but `type` is not a unique identifier if multiple DataSources share the same driver.
## Issue Context
With named connections removed, docs should not imply that `type` is a safe replacement for `name` as a unique key.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[285-294]

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

View more (13)

8. Docs still use name 🐞 Bug ✓ Correctness

Description

The logging guide still documents name inside DataSource options, but this PR removes name from
BaseDataSourceOptions and DataSource. Copying those snippets will fail TypeScript
excess-property checks and mislead users about the new API.

Code

src/data-source/BaseDataSourceOptions.ts[L19-24]

-    /**
-     * Connection name. If connection name is not given then it will be called "default".
-     * Different connections must have different names.
-     * @deprecated
-     */
-    readonly name?: string

Evidence
The PR removes the name field from the public connection options types and from DataSource
itself, while the logging docs still present name as a valid option; meanwhile the migration guide
explicitly states name was removed, making the logging page inconsistent with the rest of the
docs.
src/data-source/BaseDataSourceOptions.ts[13-25]
src/data-source/DataSource.ts[55-152]
docs/docs/advanced-topics/5-logging.md[7-18]
docs/docs/advanced-topics/5-logging.md[178-191]
docs/docs/guides/8-migration-v1.md[371-376]

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 docs page `docs/docs/advanced-topics/5-logging.md` still shows `name` in DataSource options, but `name` was removed from `BaseDataSourceOptions`/`DataSource` in this PR.
### Issue Context
This PR introduces a breaking change removing named connections; docs should not instruct users to set `name` anymore.
### Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[7-19]
- docs/docs/advanced-topics/5-logging.md[178-192]

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

9. Ambiguous config selection 🐞 Bug ✓ Correctness

Description

The migration guide demonstrates selecting a specific ormconfig entry by o.type === "postgres",
but type is not guaranteed to be unique when multiple DataSources share the same driver. This can
lead users to inadvertently pick the wrong configuration and run operations (e.g., migrations)
against the wrong database/schema.

Code

docs/docs/guides/8-migration-v1.md[R291-294]

+// when you need a specific config from multiple data sources
+const allOptions = await reader.get()
+const postgresOptions = allOptions.find((o) => o.type === "postgres")
+```

Evidence
The guide’s example selects a config by driver type only, but the repo itself contains scenarios
with multiple Postgres DataSources differentiated by schema, showing that type alone is
insufficient to identify a single config.
docs/docs/guides/8-migration-v1.md[285-294]
test/functional/data-source/data-source.test.ts[298-314]

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 migration guide example suggests selecting a specific config from multiple ormconfig entries using only `o.type === &amp;amp;amp;quot;postgres&amp;amp;amp;quot;`, but `type` is not a unique identifier if multiple DataSources share the same driver.
## Issue Context
With named connections removed, docs should not imply that `type` is a safe replacement for `name` as a unique key.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[285-294]

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

10. Generic DataSource errors 🐞 Bug ✓ Correctness

Description

After removing DataSource.name, the “already connected” / “not connected” errors no longer include
any identifier for which DataSource triggered the exception. In multi-DataSource apps/tests, this
makes failures harder to attribute without additional logging.

Code

src/error/CannotExecuteNotConnectedError.ts[R7-10]

+    constructor() {
      super(
-            `Cannot execute operation on "${connectionName}" connection because connection is not yet established.`,
+            `Cannot execute operation because connection is not yet established.`,
      )

Evidence
The updated error classes now emit fully generic messages, and DataSource throws them without any
context; the repo also demonstrates multiple DataSources of the same type coexisting, where
contextual error messages would help.
src/error/CannotExecuteNotConnectedError.ts[6-11]
src/data-source/DataSource.ts[234-236]
test/functional/data-source/data-source.test.ts[298-314]

Agent prompt

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

## Issue description
`CannotConnectAlreadyConnectedError` and `CannotExecuteNotConnectedError` are now fully generic and provide no context about which DataSource instance failed, which is less actionable in multi-DataSource applications.
## Issue Context
With `DataSource.name` removed, callers still benefit from an identifier derived from `DataSource.options` (e.g., type/database/schema/host/port).
## Fix Focus Areas
- src/error/CannotConnectAlreadyConnectedError.ts[6-11]
- src/error/CannotExecuteNotConnectedError.ts[6-11]
- src/data-source/DataSource.ts[234-236]
- src/data-source/DataSource.ts[277-279]

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

11. Ambiguous config selection 🐞 Bug ✓ Correctness

Description

The migration guide demonstrates selecting a specific ormconfig entry by o.type === "postgres",
but type is not guaranteed to be unique when multiple DataSources share the same driver. This can
lead users to inadvertently pick the wrong configuration and run operations (e.g., migrations)
against the wrong database/schema.

Code

docs/docs/guides/8-migration-v1.md[R291-294]

+// when you need a specific config from multiple data sources
+const allOptions = await reader.get()
+const postgresOptions = allOptions.find((o) => o.type === "postgres")
+```

Evidence
The guide’s example selects a config by driver type only, but the repo itself contains scenarios
with multiple Postgres DataSources differentiated by schema, showing that type alone is
insufficient to identify a single config.
docs/docs/guides/8-migration-v1.md[285-294]
test/functional/data-source/data-source.test.ts[298-314]

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 migration guide example suggests selecting a specific config from multiple ormconfig entries using only `o.type === &amp;amp;quot;postgres&amp;amp;quot;`, but `type` is not a unique identifier if multiple DataSources share the same driver.
## Issue Context
With named connections removed, docs should not imply that `type` is a safe replacement for `name` as a unique key.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[285-294]

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

12. Generic DataSource errors 🐞 Bug ✓ Correctness

Description

After removing DataSource.name, the “already connected” / “not connected” errors no longer include
any identifier for which DataSource triggered the exception. In multi-DataSource apps/tests, this
makes failures harder to attribute without additional logging.

Code

src/error/CannotExecuteNotConnectedError.ts[R7-10]

+    constructor() {
      super(
-            `Cannot execute operation on "${connectionName}" connection because connection is not yet established.`,
+            `Cannot execute operation because connection is not yet established.`,
      )

Evidence
The updated error classes now emit fully generic messages, and DataSource throws them without any
context; the repo also demonstrates multiple DataSources of the same type coexisting, where
contextual error messages would help.
src/error/CannotExecuteNotConnectedError.ts[6-11]
src/data-source/DataSource.ts[234-236]
test/functional/data-source/data-source.test.ts[298-314]

Agent prompt

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

## Issue description
`CannotConnectAlreadyConnectedError` and `CannotExecuteNotConnectedError` are now fully generic and provide no context about which DataSource instance failed, which is less actionable in multi-DataSource applications.
## Issue Context
With `DataSource.name` removed, callers still benefit from an identifier derived from `DataSource.options` (e.g., type/database/schema/host/port).
## Fix Focus Areas
- src/error/CannotConnectAlreadyConnectedError.ts[6-11]
- src/error/CannotExecuteNotConnectedError.ts[6-11]
- src/data-source/DataSource.ts[234-236]
- src/data-source/DataSource.ts[277-279]

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

13. Ambiguous config selection 🐞 Bug ✓ Correctness

Description

The migration guide demonstrates selecting a specific ormconfig entry by o.type === "postgres",
but type is not guaranteed to be unique when multiple DataSources share the same driver. This can
lead users to inadvertently pick the wrong configuration and run operations (e.g., migrations)
against the wrong database/schema.

Code

docs/docs/guides/8-migration-v1.md[R291-294]

+// when you need a specific config from multiple data sources
+const allOptions = await reader.get()
+const postgresOptions = allOptions.find((o) => o.type === "postgres")
+```

Evidence
The guide’s example selects a config by driver type only, but the repo itself contains scenarios
with multiple Postgres DataSources differentiated by schema, showing that type alone is
insufficient to identify a single config.
docs/docs/guides/8-migration-v1.md[285-294]
test/functional/data-source/data-source.test.ts[298-314]

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 migration guide example suggests selecting a specific config from multiple ormconfig entries using only `o.type === &amp;amp;amp;quot;postgres&amp;amp;amp;quot;`, but `type` is not a unique identifier if multiple DataSources share the same driver.
## Issue Context
With named connections removed, docs should not imply that `type` is a safe replacement for `name` as a unique key.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[285-294]

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

14. Generic DataSource errors 🐞 Bug ✓ Correctness

Description

After removing DataSource.name, the “already connected” / “not connected” errors no longer include
any identifier for which DataSource triggered the exception. In multi-DataSource apps/tests, this
makes failures harder to attribute without additional logging.

Code

src/error/CannotExecuteNotConnectedError.ts[R7-10]

+    constructor() {
     super(
-            `Cannot execute operation on "${connectionName}" connection because connection is not yet established.`,
+            `Cannot execute operation because connection is not yet established.`,
     )

Evidence
The updated error classes now emit fully generic messages, and DataSource throws them without any
context; the repo also demonstrates multiple DataSources of the same type coexisting, where
contextual error messages would help.
src/error/CannotExecuteNotConnectedError.ts[6-11]
src/data-source/DataSource.ts[234-236]
test/functional/data-source/data-source.test.ts[298-314]

Agent prompt

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

## Issue description
`CannotConnectAlreadyConnectedError` and `CannotExecuteNotConnectedError` are now fully generic and provide no context about which DataSource instance failed, which is less actionable in multi-DataSource applications.
## Issue Context
With `DataSource.name` removed, callers still benefit from an identifier derived from `DataSource.options` (e.g., type/database/schema/host/port).
## Fix Focus Areas
- src/error/CannotConnectAlreadyConnectedError.ts[6-11]
- src/error/CannotExecuteNotConnectedError.ts[6-11]
- src/data-source/DataSource.ts[234-236]
- src/data-source/DataSource.ts[277-279]

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

15. Ambiguous config selection 🐞 Bug ✓ Correctness

Description

The migration guide demonstrates selecting a specific ormconfig entry by o.type === "postgres",
but type is not guaranteed to be unique when multiple DataSources share the same driver. This can
lead users to inadvertently pick the wrong configuration and run operations (e.g., migrations)
against the wrong database/schema.

Code

docs/docs/guides/8-migration-v1.md[R291-294]

+// when you need a specific config from multiple data sources
+const allOptions = await reader.get()
+const postgresOptions = allOptions.find((o) => o.type === "postgres")
+```

Evidence
The guide’s example selects a config by driver type only, but the repo itself contains scenarios
with multiple Postgres DataSources differentiated by schema, showing that type alone is
insufficient to identify a single config.
docs/docs/guides/8-migration-v1.md[285-294]
test/functional/data-source/data-source.test.ts[298-314]

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 migration guide example suggests selecting a specific config from multiple ormconfig entries using only `o.type === &amp;amp;amp;quot;postgres&amp;amp;amp;quot;`, but `type` is not a unique identifier if multiple DataSources share the same driver.
## Issue Context
With named connections removed, docs should not imply that `type` is a safe replacement for `name` as a unique key.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[285-294]

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

16. Generic DataSource errors 🐞 Bug ✓ Correctness

Description

After removing DataSource.name, the “already connected” / “not connected” errors no longer include
any identifier for which DataSource triggered the exception. In multi-DataSource apps/tests, this
makes failures harder to attribute without additional logging.

Code

src/error/CannotExecuteNotConnectedError.ts[R7-10]

+    constructor() {
      super(
-            `Cannot execute operation on "${connectionName}" connection because connection is not yet established.`,
+            `Cannot execute operation because connection is not yet established.`,
      )

Evidence
The updated error classes now emit fully generic messages, and DataSource throws them without any
context; the repo also demonstrates multiple DataSources of the same type coexisting, where
contextual error messages would help.
src/error/CannotExecuteNotConnectedError.ts[6-11]
src/data-source/DataSource.ts[234-236]
test/functional/data-source/data-source.test.ts[298-314]

Agent prompt

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

## Issue description
`CannotConnectAlreadyConnectedError` and `CannotExecuteNotConnectedError` are now fully generic and provide no context about which DataSource instance failed, which is less actionable in multi-DataSource applications.
## Issue Context
With `DataSource.name` removed, callers still benefit from an identifier derived from `DataSource.options` (e.g., type/database/schema/host/port).
## Fix Focus Areas
- src/error/CannotConnectAlreadyConnectedError.ts[6-11]
- src/error/CannotExecuteNotConnectedError.ts[6-11]
- src/data-source/DataSource.ts[234-236]
- src/data-source/DataSource.ts[277-279]

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

17. Ambiguous config selection 🐞 Bug ✓ Correctness

Description

The migration guide demonstrates selecting a specific ormconfig entry by o.type === "postgres",
but type is not guaranteed to be unique when multiple DataSources share the same driver. This can
lead users to inadvertently pick the wrong configuration and run operations (e.g., migrations)
against the wrong database/schema.

Code

docs/docs/guides/8-migration-v1.md[R291-294]

+// when you need a specific config from multiple data sources
+const allOptions = await reader.get()
+const postgresOptions = allOptions.find((o) => o.type === "postgres")
+```

Evidence
The guide’s example selects a config by driver type only, but the repo itself contains scenarios
with multiple Postgres DataSources differentiated by schema, showing that type alone is
insufficient to identify a single config.
docs/docs/guides/8-migration-v1.md[285-294]
test/functional/data-source/data-source.test.ts[298-314]

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 migration guide example suggests selecting a specific config from multiple ormconfig entries using only `o.type === &amp;amp;amp;amp;quot;postgres&amp;amp;amp;amp;quot;`, but `type` is not a unique identifier if multiple DataSources share the same driver.
## Issue Context
With named connections removed, docs should not imply that `type` is a safe replacement for `name` as a unique key.
## Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[285-294]

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

18. Generic DataSource errors 🐞 Bug ✓ Correctness

Description

After removing DataSource.name, the “already connected” / “not connected” errors no longer include
any identifier for which DataSource triggered the exception. In multi-DataSource apps/tests, this
makes failures harder to attribute without additional logging.

Code

src/error/CannotExecuteNotConnectedError.ts[R7-10]

+    constructor() {
     super(
-            `Cannot execute operation on "${connectionName}" connection because connection is not yet established.`,
+            `Cannot execute operation because connection is not yet established.`,
     )

Evidence
The updated error classes now emit fully generic messages, and DataSource throws them without any
context; the repo also demonstrates multiple DataSources of the same type coexisting, where
contextual error messages would help.
src/error/CannotExecuteNotConnectedError.ts[6-11]
src/data-source/DataSource.ts[234-236]
test/functional/data-source/data-source.test.ts[298-314]

Agent prompt

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

## Issue description
`CannotConnectAlreadyConnectedError` and `CannotExecuteNotConnectedError` are now fully generic and provide no context about which DataSource instance failed, which is less actionable in multi-DataSource applications.
## Issue Context
With `DataSource.name` removed, callers still benefit from an identifier derived from `DataSource.options` (e.g., type/database/schema/host/port).
## Fix Focus Areas
- src/error/CannotConnectAlreadyConnectedError.ts[6-11]
- src/error/CannotExecuteNotConnectedError.ts[6-11]
- src/data-source/DataSource.ts[234-236]
- src/data-source/DataSource.ts[277-279]

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

19. Generic DataSource errors 🐞 Bug ✓ Correctness

Description

After removing DataSource.name, the “already connected” / “not connected” errors no longer include
any identifier for which DataSource triggered the exception. In multi-DataSource apps/tests, this
makes failures harder to attribute without additional logging.

Code

src/error/CannotExecuteNotConnectedError.ts[R7-10]

+    constructor() {
     super(
-            `Cannot execute operation on "${connectionName}" connection because connection is not yet established.`,
+            `Cannot execute operation because connection is not yet established.`,
     )

Evidence
The updated error classes now emit fully generic messages, and DataSource throws them without any
context; the repo also demonstrates multiple DataSources of the same type coexisting, where
contextual error messages would help.
src/error/CannotExecuteNotConnectedError.ts[6-11]
src/data-source/DataSource.ts[234-236]
test/functional/data-source/data-source.test.ts[298-314]

Agent prompt

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

## Issue description
`CannotConnectAlreadyConnectedError` and `CannotExecuteNotConnectedError` are now fully generic and provide no context about which DataSource instance failed, which is less actionable in multi-DataSource applications.
## Issue Context
With `DataSource.name` removed, callers still benefit from an identifier derived from `DataSource.options` (e.g., type/database/schema/host/port).
## Fix Focus Areas
- src/error/CannotConnectAlreadyConnectedError.ts[6-11]
- src/error/CannotExecuteNotConnectedError.ts[6-11]
- src/data-source/DataSource.ts[234-236]
- src/data-source/DataSource.ts[277-279]

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

20. Generic DataSource errors 🐞 Bug ✓ Correctness

Description

After removing DataSource.name, the “already connected” / “not connected” errors no longer include
any identifier for which DataSource triggered the exception. In multi-DataSource apps/tests, this
makes failures harder to attribute without additional logging.

Code

src/error/CannotExecuteNotConnectedError.ts[R7-10]

+    constructor() {
    super(
-            `Cannot execute operation on "${connectionName}" connection because connection is not yet established.`,
+            `Cannot execute operation because connection is not yet established.`,
    )

Evidence
The updated error classes now emit fully generic messages, and DataSource throws them without any
context; the repo also demonstrates multiple DataSources of the same type coexisting, where
contextual error messages would help.
src/error/CannotExecuteNotConnectedError.ts[6-11]
src/data-source/DataSource.ts[234-236]
test/functional/data-source/data-source.test.ts[298-314]

Agent prompt

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

## Issue description
`CannotConnectAlreadyConnectedError` and `CannotExecuteNotConnectedError` are now fully generic and provide no context about which DataSource instance failed, which is less actionable in multi-DataSource applications.
## Issue Context
With `DataSource.name` removed, callers still benefit from an identifier derived from `DataSource.options` (e.g., type/database/schema/host/port).
## Fix Focus Areas
- src/error/CannotConnectAlreadyConnectedError.ts[6-11]
- src/error/CannotExecuteNotConnectedError.ts[6-11]
- src/data-source/DataSource.ts[234-236]
- src/data-source/DataSource.ts[277-279]

ⓘ 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

Previous review results

Review updated until commit 6f2bd51

Results up to commit 1248ca5

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

1. Config paths not applied 🐞 Bug ✓ Correctness

Description

ConnectionOptionsReader.normalizeConnectionOptions computes absolute
entities/subscribers/migrations paths but assigns them to the options array object instead of
the per-DataSourceOptions entry, so consumers still receive unnormalized relative globs and class
discovery can fail when the working directory differs from the config root.

Code

src/connection/ConnectionOptionsReader.ts[R40-43]

+    async get(): Promise<DataSourceOptions[]> {
      const options = await this.load()
      if (!options)
          throw new TypeORMError(

Evidence

After this PR, ConnectionOptionsReader.get()<...

… and simplify API

qodo-free-for-open-source-projects · 2026-03-09T10:42:10Z

Persistent review updated to latest commit f4d35c3

qodo-free-for-open-source-projects · 2026-03-09T11:00:13Z

Persistent review updated to latest commit 9e17ad7

qodo-free-for-open-source-projects · 2026-03-09T11:45:03Z

Persistent review updated to latest commit 1248ca5

sonarqubecloud · 2026-03-09T11:55:25Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
21.1% Duplication on New Code

See analysis details on SonarQube Cloud

qodo-free-for-open-source-projects · 2026-03-09T12:01:29Z

Persistent review updated to latest commit 6f2bd51

pkuczynski added this to the 1.0 milestone Mar 8, 2026

pkuczynski self-assigned this Mar 8, 2026

pkuczynski requested review from alumni, gioboa and naorpeled March 8, 2026 10:14

pkuczynski enabled auto-merge (squash) March 8, 2026 10:43

gioboa approved these changes Mar 8, 2026

View reviewed changes

refactor(ConnectionOptionsReader)!: remove deprecated DataSource.name…

f4d35c3

… and simplify API

pkuczynski force-pushed the refactor/remove-deprecated-datasource-name branch from fbe2899 to f4d35c3 Compare March 9, 2026 10:36

alumni approved these changes Mar 9, 2026

View reviewed changes

fix(ci): update ormconfig jq filters and remove deprecated name field

1248ca5

pkuczynski force-pushed the refactor/remove-deprecated-datasource-name branch from 9e17ad7 to 1248ca5 Compare March 9, 2026 11:39

Merge branch 'master' into refactor/remove-deprecated-datasource-name

6f2bd51

pkuczynski merged commit 8a9f0b9 into master Mar 9, 2026
39 checks passed

pkuczynski deleted the refactor/remove-deprecated-datasource-name branch March 9, 2026 12:22

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

refactor(ConnectionOptionsReader)!: remove deprecated DataSource.name and simplify API#12136

refactor(ConnectionOptionsReader)!: remove deprecated DataSource.name and simplify API#12136
pkuczynski merged 3 commits intomasterfrom
refactor/remove-deprecated-datasource-name

pkuczynski commented Mar 8, 2026

Uh oh!

cloudflare-workers-and-pages bot commented Mar 8, 2026 •

edited

Loading

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 8, 2026

Uh oh!

pkg-pr-new bot commented Mar 8, 2026 •

edited

Loading

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 8, 2026 •

edited

Loading

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 9, 2026

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 9, 2026

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 9, 2026

Uh oh!

sonarqubecloud bot commented Mar 9, 2026

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

pkuczynski commented Mar 8, 2026

Uh oh!

cloudflare-workers-and-pages bot commented Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying typeorm with Cloudflare Pages

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 8, 2026

Review Summary by Qodo

Walkthroughs

File Changes

Uh oh!

pkg-pr-new bot commented Mar 8, 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 Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Previous review results

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 9, 2026

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 9, 2026

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 9, 2026

Uh oh!

sonarqubecloud bot commented Mar 9, 2026

Quality Gate passed

Uh oh!

qodo-free-for-open-source-projects bot commented Mar 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

cloudflare-workers-and-pages bot commented Mar 8, 2026 •

edited

Loading

pkg-pr-new bot commented Mar 8, 2026 •

edited

Loading

qodo-free-for-open-source-projects bot commented Mar 8, 2026 •

edited

Loading