Is there an existing feature request for this?

No

Problem description

TypeORM v1.0.0 is approaching release (tracking issue: typeorm/typeorm#11819, targeting March 2026). Nightly builds are already available (1.0.0-nightly.20260313).

TypeORM v1.0.0 removes all deprecated APIs, most notably:

• The Connection class (replaced by DataSource since 0.3.0)
• The createConnection() function
• connection.close() (now dataSource.destroy())
• connection.isConnected (now dataSource.isInitialized)

@nestjs/typeorm@11.0.0 will crash at startup with TypeORM v1.0.0. The application cannot bootstrap at all — this is a hard blocker for every NestJS+TypeORM project.

What breaks

Two places in lib/typeorm-core.module.ts reference the removed APIs:

1. Connection provider registration (lines 13-14, lines 66-73, lines 124-131)

Connection and createConnection are imported from typeorm at the top of the file:

import {
  Connection,
  createConnection,
  DataSource,
  DataSourceOptions,
} from 'typeorm';

Both forRoot() and forRootAsync() register Connection as an alias for DataSource. There's even a TODO comment anticipating this removal:

// TODO: "Connection" class is going to be removed in the next version of "typeorm"
if (dataSourceProvider.provide === DataSource) {
  providers.push({
    provide: Connection,       // undefined in TypeORM v1.0.0
    useExisting: DataSource,
  });
  exports.push(Connection);   // undefined in TypeORM v1.0.0
}

Pushing undefined into the providers/exports arrays crashes NestJS's DI container:

TypeError: Cannot read properties of undefined (reading 'provide')
  at Module.isCustomProvider (node_modules/@nestjs/core/injector/module.js:185:52)
  at Module.addExportedProviderOrModule (node_modules/@nestjs/core/injector/module.js:285:18)

2. createConnection fallback (lines 207-213)

const createTypeormDataSource =
  dataSourceFactory ??
  ((options: DataSourceOptions) => {
    return DataSource === undefined
      ? createConnection(options)   // createConnection is also removed in v1.0.0
      : new DataSource(options);
  });

This fallback is dead code (since DataSource exists in both 0.3 and 1.0), but it will cause confusion and should be cleaned up.

How I found this

I upgraded Vendure (74 entities, 1,827 e2e tests, 3 DB drivers) to TypeORM 1.0.0-nightly.20260313 to audit breaking changes for the TypeORM migration guide. This was the first and most critical issue — 0% of tests could run until patched.

Proposed solution

Guard or remove the Connection backwards-compat code:

// Option A: Guard with existence check (supports both 0.3 and 1.0)
if (dataSourceProvider.provide === DataSource && Connection) {
  providers.push({
    provide: Connection,
    useExisting: DataSource,
  });
  exports.push(Connection);
}

// Option B: Remove entirely (if dropping 0.3 compat in next major)
// Just delete the Connection provider block and the createConnection fallback

Also remove the createConnection fallback — DataSource has existed since TypeORM 0.3.0 and the fallback is unreachable.

The peerDependencies would need updating from "typeorm": "^0.3.0" to include v1: "typeorm": "^0.3.0 || ^1.0.0" (or just >=0.3.0).

Teachability, currentbility, maintenance

Option A (guard check) is fully backwards-compatible — it works with both TypeORM 0.3.x and 1.0.0 without any changes needed by end users. This could ship as a minor/patch release of @nestjs/typeorm.

Option B (remove Connection compat entirely) would be a breaking change for anyone still injecting Connection in their NestJS providers, which would warrant a major version bump.

What is the motivation / use case for this feature?

TypeORM v1.0.0 is the next major release and every NestJS+TypeORM project will need @nestjs/typeorm to support it. Since this is a hard crash (not a deprecation warning), users won't be able to incrementally migrate — they'll be completely blocked until a compatible version of @nestjs/typeorm is released.

Filing this early so there's time to coordinate before the TypeORM v1.0.0 stable release.