migration:up

[wguerram]

Describe the bug
Hello I've manage to create the initial migrations ts file but when I run migration:up looks like the migration up is not being run.

I just don't know what else todo. what am i missing?

Stack trace

I get a successful message but the tables are not being created.

Successfully migrated up to the latest version
...

To Reproduce
Steps to reproduce the behavior:

1. ... create an initial migration
2. ... run migration:up

Expected behavior
I'm expecting the up method to be executed.

Additional context

Versions

Dependency	Version
node	v14.17.6
typescript	4.3.5
mikro-orm	5.0.0-dev.382
your-driver	mariadb

[genu]

Are you able to run schema:create successfully?

[wguerram]

Yes, schema:create does create the database and tables.

[genu]

Do you have a migrations table that is created as well? Does it have any data there?

[wguerram]

When I run migration:up the migration table is created but empty

[Langstra]

Maybe a misconfiguration? What does migration:pending say? Could be that your cli is looking for js files instead of ts?

Please provide a reproduction repo so we can help you better.

[wguerram]

From the output it seems to read ts files, also migrations:create is creating the migration.ts file, so I think is reading ts files correctly.

migration:pending outputs:

[discovery] - entity discovery finished, found 46 entities, took 2168 ms
[info] MikroORM successfully connected to database
[query] select table_name as table_name, nullif(table_schema, schema()) as schema_name, table_comment as table_comment from information_schema.tables where table_type = 'BASE TABLE' and table_schema = schema() [took 3 ms]
[query] select * from mikro_orm_migrations order by id asc [took 3 ms]
No pending migrations

[Langstra]

If your migrations table is empty then it leads me to believe that your configuration is wrong. But as I said before, please create a reproduction so we can have a look.

[wguerram]

Hello, so in the process of creating a reproduction I identified my issue is related to the .env file. after removing the config variables from my .env file it worked. So the question I have now is it possible to use the CLI with the configuration in an .env file only or it's mandatory to use a mikro-orm.config.ts file? I was hoping on not adding mikro-orm to my package.json and not creating a mikro-orm.config.ts.

I tried adding thes two to my .env file but it keeps looking Error: MikroORM config file not found in ['./mikro-orm.config.js']
MIKRO_ORM_CLI_USE_TS_NODE=true
MIKRO_ORM_CLI=./mikro-orm.config.ts

Thanks for your help.

[genu]

I haven't verified, but you should be able to drive mikro-orm from only env vars.

See: https://mikro-orm.io/docs/configuration/#using-environment-variables

[wguerram]

Thanks @genu that's my thinking. I can run the application from .env, the problem I have is with the CLI

The ones related to the CLI are missing in the example and I can't find a working example of .env and CLI.

[genu]

🤔 From what I can tell, if the config doesn't exist, it checks for envs:

mikro-orm/packages/core/src/utils/ConfigurationLoader.ts

Lines 40 to 44 in f16b236

	if (Utils.hasObjectKeys(env)) {
	return new Configuration({ ...options, ...env }, validate);
	}
	throw new Error(`MikroORM config file not found in ['${paths.join(`', '`)}']`);

Have you made sure that env vars are loaded and set before CLI executes?

[wguerram]

Hi, yes the env variables are being loaded.

[genu]

how are you checking that they are loaded?

[B4nan]

I havent read this very carefully, but:

I was hoping on not adding mikro-orm to my package.json and not creating a mikro-orm.config.ts.

I don't follow how you expect things to work if you don't install the ORM. You don't need to have ORM config if you provide everything needed via env vars, but not everything is configurable via env vars (e.g. you can't pass classes or instances that way and some things like subscribers can't be setup differently).

Also note that you might not need/want to use initial migration. They are designed for a specific use case where you might already have the schema set up but want to start using migrations. If you do not have any schema and just have entities, drop the initial flag and just create new migration. They you need to run it (via migration:up CLI command).

An initial migration, if you already have the schema set up, will be automatically marked as executed, therefore added to the list you get via migration:list.

🤔 From what I can tell, if the config doesn't exist, it checks for envs:

Env vars are checked always. They have precedence over what is in the ORM config file. That code you highlighted is just a validation, if there are no env vars, no CLI config and no ORM config provided in the init() method, this error will be triggered.

Lastly, it is always better to provide a reproduction repository if you struggle with describing something. Code is almost always more worthy than words in this context.

[wguerram]

I forked the Koa example with an .env file and removed the mikro config from package.json, if you run npx mikro-orm migration:create you'll get an error.

https://github.com/wguerram/koa-ts-example-app

[B4nan]

you'll get an error.

What about sharing what error is that? With a stack trace.

[wguerram]

@B4nan

`
C:\dev\koa-ts-example-app\app\mikro-orm.config.ts:1
import { Options } from "@mikro-orm/core";
^^^^^^

SyntaxError: Cannot use import statement outside a module
at wrapSafe (internal/modules/cjs/loader.js:988:16)
at Module._compile (internal/modules/cjs/loader.js:1036:27)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)
at Module.load (internal/modules/cjs/loader.js:937:32)
at Function.Module._load (internal/modules/cjs/loader.js:778:12)
at Module.require (internal/modules/cjs/loader.js:961:19)
at require (internal/modules/cjs/helpers.js:92:18)
at MetadataDiscovery.getEntityClassOrSchema (C:\dev\koa-ts-example-app\node_modules@mikro-orm\core\metadata\MetadataDiscovery.js:689:25)
at MetadataDiscovery.discoverDirectories (C:\dev\koa-ts-example-app\node_modules@mikro-orm\core\metadata\MetadataDiscovery.js:104:34)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
at async MetadataDiscovery.findEntities (C:\dev\koa-ts-example-app\node_modules@mikro-orm\core\metadata\MetadataDiscovery.js:70:9)
at async MetadataDiscovery.discover (C:\dev\koa-ts-example-app\node_modules@mikro-orm\core\metadata\MetadataDiscovery.js:34:9)
at async Function.init (C:\dev\koa-ts-example-app\node_modules@mikro-orm\core\MikroORM.js:42:24)
at async Function.handleMigrationCommand (C:\dev\koa-ts-example-app\node_modules@mikro-orm\cli\commands\MigrationCommandFactory.js:70:21)

`

[B4nan]

That means you are trying to load TS config file without ts-node support enabled, it has nothing to do with migrations. You said you removed the file from package.json, but the file itself is still present, and linked via your .env file (https://github.com/wguerram/koa-ts-example-app/blob/master/.env#L15).

[B4nan]

Also note that you are trying to use env vars that are not present in v4 (e.g. the one for enabling ts-node support in CLI) - those are only in v5.

[LazeKer]

I have the same problem, on windows (using the version 5.4.1-dev.13 to have this fix), and after some debugging I noticed that it could be related to Umzug, used under the hood, that does not handle glob with \ in the path properly.

If I replace them just before giving it to Umzug it fixes the problem.
By replacing:

let migrations: InputMigrations<any> = {
  glob: join(this.absolutePath, this.options.glob!),
  resolve: (params: MigrationParams<any>) => this.resolve(params),
};

with:

let migrations: InputMigrations<any> = {
  glob: join(this.absolutePath, this.options.glob!).replaceAll('\\', '/'),
  resolve: (params: MigrationParams<any>) => this.resolve(params),
};

(located here)

Hope this helps!

[B4nan]

So what should I do to reproduce? I finally bootstrapped windows inside parallels so I can test fix such issues quite easily (for next few days before the trial expires I guess :D).

[B4nan]

Ok I see, it does not error but it fails to find the migration files without the change you mentioned. Thanks for the notice!

[LazeKer]

Yes exactly, it "just" doesn't find the migrations without throwing errors.
Glad it helped! Nice work with this ORM by the way!

[micahbule]

Hi @B4nan! First of, awesome library. Been a while since I got my hands on ORMs, and it was a delight using MikroORM.

So, I spent a whole day trying to figure out why the migration script is executing successfully yet my tables aren't created on a fresh deployment.

While it took me a while to realize what was wrong, it was actually your comment that gave me the realization that I may have been confused between migrations and schema generation, especially from someone who came from Laravel (1 that is) where I had to write the actual migrations myself.

To help others in my situation, I would like to suggest two things:

• Update the docs for both migration and schema generation with emphasis on their usage
• Add a warning log during migration if no tables currently exist in the database

[micahbule]

@B4nan they are all within the migrations folder of the NestJS application. I even configured the build script of NestJS to include the snapshot JSON file (which was left out by default) as I suspected the migrations aren't running properly without that. I also followed https://mikro-orm.io/docs/migrations#running-migrations-in-production where I needed to configure the migration paths properly for both the src and dist folder. All of which to no avail.

[B4nan]

I suspected the migrations aren't running properly without that.

It's rather the opposite, snapshots are development feature, and this sounds like having the snapshot in production is causing the troubles you had.

[B4nan]

But I think snapshots shouldn't be taken into account when running migrations, it's supposed to be used only for creating them.

[micahbule]

I'll try to post steps to reproduce the issue if ever. Thanks for the very quick response!

[B4nan]

One common issue with running migrations in production is that you only have the TS files, and without having ts-node installed (as you have that as dev dep and you might install only prod deps in there), they will be ignored. Maybe that's what happened? The ORM will try to infer defaults for both JS and TS migrations, but the default migrations folder is in root, and that is often not part of what you compile (e.g. you usually have a src folder and compile only that).