TypeORM: Migrate THEN generate new migration? - typeorm

Question

This is probably a dumb question, but it seems like a reasonable use case to me (unless I'm missing some obvious mistake). Here's where I'm at:
In production, I wish to provide database connection parameters via environment variables to connect to a database hosted off-site (e.g. in AWS)
In production I need to be able to apply migrations to the database easily using the TypeORM CLI (typeorm migration:run)
In development, I wish to provide a docker-compose.yml file so that new developers can quickly spin up a working copy of my application using docker-compose up -d, and quickly see the results of their code changes (I'm still working on a solution to watch for changes and re-compile, because my application is written in TypeScript and has to be built before it can be run)
For my unit tests, I want to spin up an empty database in order to populate it with hard-coded data on each test (ensuring idempotency and consistency of tests) and I want these tests to be performant and low-cost
In development I wish to be able to create migrations easily using the TypeORM CLI (typeorm migration:generate) -- this is where I'm having trouble
In production TypeORM will read from the environment variables by default, so this works fine out of the box. I can even run typeorm migration:run and, assuming the connection parameters are correct, it works.
Because I'm using Docker Compose to spin up a working copy of the application in development, I can supply environment variables in the docker-compose.yml file so that my application can connect to the database within Docker. This is fine -- still using environment variables for everything.
For the unit tests, I integrate TypeORM into my application like so (this is a HapiJS plugin):
import * as path from "path";
import * as Hapi from "#hapi/hapi";
import {createConnection, getConnectionOptions} from "typeorm";
export default {
name: "TypeORM",
version: "1.0.0",
register: async function (server:Hapi.Server, options:Hapi.ServerRegisterOptions)
{
const connectionOptions = await getConnectionOptions();
Object.assign(connectionOptions, {
entities: [path.join(__dirname, "../models/**/*")],
migrations: [path.join(__dirname, "../migrations/**/*")],
// subscribers: [path.join(__dirname, "../subscribers/**/*")],
synchronize: false
});
if ((options as any).useInMemoryDb)
{
console.log("Switching to in-memory database for unit testing");
Object.assign(connectionOptions, {
type: "sqlite",
host: null,
port: null,
username: null,
password: null,
database: ":memory:",
synchronize: true
});
}
const connection = await createConnection(connectionOptions);
server.decorate("server", "getConnectionManager", () => connection.manager);
server.decorate("server", "getConnection", () => connection);
}
};
Now in my unit tests I simply set useInMemoryDb to true and it will ignore the environment variables and instead spin up an in-memory Sqlite database. Since it's in-memory it's very performant, but has limitations on the amount of data it can hold and lacks persistence -- both problems that don't matter for unit tests. Since it's Sqlite and not MySQL that does limit me to a subset of SQL operations, but that's fine -- we simply document what features are not supported and ensure developers stick to the SQL spec.
Now for the problem of creating migrations...
If I type typeorm migration:generate on a development machine, it will fail because there are no connection options (no environment variables are set). Oddly, I tried creating a .env file to set the environment variables, but TypeORM didn't read the file despite the documentation saying it would (I still got a "no connection options were found" error). I could work around this by creating an ormconfig.json file, instead. However this is where I run into a snag.
Because I'm using Docker Compose to run my application in development, the database lives inside of an ephemeral container with no exposed ports that may not even be running when someone attempts to create a migration. The ormconfig.json file must therefore point to something that I can guarantee exists on the developer's machine. I can't trust that a developer has MySQL or Postgres or anything else installed, so I fall back to Sqlite.
If I use an in-memory Sqlite database and set synchronize: true, then no migrations are created because the database always matches my model definition. If I use an in-memory Sqlite database and set synchronize: false, then the migration created includes all tables and columns, not just new ones. I need to perform a migration:run before I perform a migration:generate, but if I just put something like typeorm migration:run && typeorm migration:generate into my NPM script, then the Sqlite database has been destroyed by the time migration:run finishes running and migration:generate starts.
I considered writing to a Sqlite database on disk and cleaning it up when I was done (e.g. typeorm migration:run && typeorm migration:generate && rm tmpdb) but I don't like the idea of the ormconfig.json specifying a file on disk as this file then needs to be excluded in the .gitignore and may accidentally be created by some one-off code execution (e.g. someone running the application without using Docker Compose)
I also don't like that I only want to spin up a single-use database for this one specific use case (generating a migration) yet in order for the CLI to find the configuration options I'm having to specify them in a global configuration file (ormconfig.json) -- this feels very hacky. A one-off use case should utilize a one-off solution, not something with lord knows how many side effects.
So is there a solution to this general problem? I want to be able to generate migrations based on my model definitions and my existing migrations, regardless of the existence of a database at the time that migration:generate is run.