But you can't give me an example how, and want one from me instead?

You have a whole repository, with tests, at your disposal. Have you looked at it? Everything you need to know is there, and you have something specific to ask, please do. I don't get what is so hard to understand how this implementation works, so I'm asking to help you.

We have a function that takes patterns (and optional argument with additional options):

import {discoverEntities} from "@mikro-orm/core/discovery"

const discovery = discoverEntities(["src/db/entities/**/*.ts"])

This code will create async generator function, now, this function takes Confuguration instance, so you can have baseDir and other params if you need within that generator.

Then somewhere inside of Mikro ORM code you call that function to create an object that implements iterator protocol (and since Mikro ORM allows to pass classes to entity option you'll need to check whether it async generator function or array, obviously):

const iterator = discovery(this.configuration) // doesn't matter where Configuration comes from, it will depend on how you'd implement the internals

Now Mikro ORM can consume it via for-await-of or Array.fromAsync and do whatever you want with it. Each iteration yields a path to original file and its exports, as I already said. So, that would be:

for await (const {path, exports} of iterator) {
  // Extract metadata, add entity to the cache and so on.
}

Again, how entities will be consumed internally is up to you, but my implementation assumes that this is done either in MikroORM.init somewhere (it's async) or lazily (for instance when you call orm.connect), so there are 3 key points here:

• Folder-based discovery means entity takes async iterator function as one of supported values;
• discoverEntities does not read entities right away (unlike in your proposal)
• It entities consumed asynchronously (because it's async iterator)

And as I said there should be no difference for CLI point of view:

Let's say we have our orm config defined somewhere at project, like src/lib/db/config.ts:

import {discoverEntities} from "@mikro-orm/core/discovery"
import {defineConfig} from "@mikro-orm/better-sqlite"

export const config = defineConfig({
  dbName: ":memory:",
  entities: discoverEntities(["src/db/entities/**/*.ts"], {
    // Additional options
    loader: "tsx" // if I find time to spare to re-do my PR before v7 release :D
  })
})

Now how CLI can use it:

// We read our plain configuration object
const config = await loadConfig(cliOptions)

const orm = new MikroORM(config)

await orm.connect() // This is where we initialize everything we need to establish connection, and maybe consume `config.entities`

// Now we can do stuff, like migrations, seeding, refreshing schema etc, depending on the command

await orm.disconnect()

This is no different for CLI comparing to how it works now – all necessary job happens inside Mikro ORM, we just move require/import outside of the core and add code to consume this iterator. This also solves the problem with baseDir and other configuration options - you can have it, because iterator itself is created later on. I hope this helps to understand it better.

Another thing I don't understand about your proposal is that the TS support is now wired into it - we need TS support in the CLI and for a few other things, e.g. migrations, seeding, config loading for the CLI as well, even if we remove it from the init method. And we need all of this to work for programatic use as well, not just for the CLI.

TypeScript support was supposed to be part of the loaders from #6333 or however you do it, doesn't matter. For discovery it may as well be replaces with dynamic import (with or without SWC/ts-node or whatever you'll use).

I also had an idea for unified loadConfig logic and you can find it in my repository. The idea was to remove dynamic imports from the core + bring more options for TS support (tsx, jiti, swc, etc).

I think the main thing I misunderstood about this was the idea of passing a function instead of the actual entities. It sounds like an elegant way to deal with this, but if we were to make the folder-based discovery lazy (run it similarly to the connect method), we would lose the ability to access repositories - em.getRepository needs to know the metadata, because a custom repository class can be used. There are other things that could be problematic with the lazy discovery. I can imagine people might use the entity metadata in their projects too, and orm.getMetadata wouldn't work.

I was thinking of a different flow, users would have to await the discoverEntities method, which would return class references, so the ORM init would always be sync, and would always get the class references, never string paths. We could get rid of the static init method completely (with the recent changes, the only real difference is that it runs the async discovery: https://github.com/mikro-orm/mikro-orm/blob/v7/packages/core/src/MikroORM.ts#L47-L50, everything else happens in the constructor). But for that, some issues I tried to point out above would arise - options like preferTs wouldn't be available unless passed to that method explicitly (so duplicating its presence, since it would still be required in the main ORM config). But maybe that's the only real issue (plus of course baseDir), and given the preferTs value should be set manually only for tests (and that baseDir should be ideally the default process.cwd()), it might be all right to just ignore this duplication, rely on the same defaults in both places (and allow manual override to deal with edge cases explicitly).

Then we could have the discoverEntities and discoverEntitiesSync (using require for CJS) as I described in the OP, returning the class references, making the ORM config only accept class references and nothing else (and making the static init method unnecessary). But there is another gotcha, the discovery hooks can be async, for those, the async init method is now required. That could maybe be worked around by delaying the metadata hooks for the connect event. Or maybe we could just make them always sync, IMO they should be used for metadata manipulation, you usually don't need any async stuff for this kind of job.

So to summarize, I would prefer:

• getting rid of the init method
• making discovery hooks sync only
• only accepting list of class reference in the ORM config
• moving the folder-based discovery to the new discoverEntities helper
  • it would return that eagerly
  • it would have sync CJS alternative using require
  • it would infer TS support via Utils.detectTypeScriptSupport() like the ORM does, and have an explicit option to override the detection
  • open question: does this really need to be a separate package (or a named export)? we still have other places that use node:fs, right?

Alternatively, we could:

• keep the async init method and keep async discovery hooks
• return async callback from the discoverEntities helper
• call that as part of the init method
• throw if we see an async callback in the constructor

Any thoughts/preferences @boenrobot ? I kinda like the idea of having only the sync entrypoint, especially now when the async one is so thin. And it would also push people into using the class references, unlocking better type safety (e.g. for #6939).

I was experimenting with both proposals, this is what I ended up with: #6993

I kept the async init method, and entitiesTs option, the user facing API stayed the same, strings are still part of the options interface, but available only with the async init method. It builds on top of #6992, which made it simple to also implement my proposal with awaiting the discoverEntities call.

I am importing that particular file dynamically, when testing it with vite, you end up with that in a separate chunk by default. Is that fine or would we rather have to force explicit import + usage of the discoverEntities function?

edit: thinking a bit more about this, since the folder-based discovery won't work for bundlers, it might be better to import through a helper (so the bundler wont understand there is something to be bundled), that way the chunk won't be even emitted, and we will keep the same API

I went ahead and merged #6993, since it only changed internals and the public API and behavior stayed the same. I am open to make further changes if necessary.

I am reviewing the code, and even though the tinyglobby dependency is super small, maybe we could drop it too (make it an optional peer). We don't really use it anywhere outside of the file discovery. The other two places in the core package are the CLI debug command (not very important) and cleanup in the FileCacheAdapter (should be doable without it).

Or we could just use the native glob in nodejs, I see it was stabilized in v22.17.0. I guess I will give that a try first.

edit: I guess I will keep the dependency for the seeder package, since we need brace expansion in there (same for migrations, but we use umzug there, which handles globbing on its own).