v0.7.5
nauth migrations connected without TLS
Schema migrations run on their own DataSource, built from your connection settings so that your migrations are never touched. It copied your credentials — host, port, user, password, database, extra — but not ssl. Every migration run since the isolated DataSource shipped therefore opened an unencrypted connection, on both Postgres and MySQL, regardless of the TLS settings on your own pool.
There was nothing to see. The application's own connection was encrypted as configured, the migrations applied, startup succeeded. The only visible symptom was on a server that refuses plaintext: the second connection is rejected and the app dies at boot with a connection error that names nothing recognisable, because the pool raising it is not one you created.
// Your DataSource — encrypted, as intended
new DataSource({
type: 'postgres',
host: process.env.DB_HOST,
ssl: { rejectUnauthorized: false },
// ...
});
// What nauth used to open alongside it: same credentials, ssl absent
ssl is now copied across, for both the individual-parameter and the connection-URL forms. No configuration change on your side — the migration connection simply inherits the TLS settings you already have.
ssl through extra as a workaround?extra was always copied, and TypeORM spreads it over the driver config, so passing TLS settings that way worked. It still does, and it is now redundant. Removing it is safe; leaving it is harmless.
Two more options it dropped
The same omission, one step milder, and fixed in the same place:
| Option | Driver | What went wrong |
|---|---|---|
schema | Postgres | nauth tables were created in the search-path default while your DataSource read them from your schema |
socketPath | MySQL | a socket-only consumer fell back to a TCP connection that may not exist |
Pool sizing, charset, timezone and connectTimeout are still deliberately not copied — the migration DataSource is short-lived and runs DDL only, and table charset comes from the database default rather than the connection.
See TypeORM Postgres and TypeORM MySQL.