import { Configuration } from '@spinajs/configuration-common';
import { AsyncService, ClassInfo } from '@spinajs/di';
import { Log } from '@spinajs/log-common';
import { OrmMigration } from './interfaces.js';
/**
 * Fallback for `system.dirs.migrations` when that key is absent or empty - see the comment on it
 * in `config/orm.ts` for why the defaults live here rather than shipping in the config value
 * itself. One entry per format-independent build layout a project might have been compiled to; a
 * migration reachable through more than one resolves to the same class name twice and is deduped
 * by `Orm`.
 *
 * `lib/migrations` alone used to stand in for "the compiled layout", but every package in this
 * repo compiles to `lib/cjs` and `lib/mjs` - there is no bare `lib/migrations` anywhere spinajs
 * itself produces, which made the filesystem source a silent no-op for a deployment built the
 * spinajs way. `build/migrations` and bare `migrations` are added alongside the original three
 * rather than replacing them, so an existing `src/lib/dist` layout keeps working unchanged.
 *
 * `lib/cjs/migrations` and `lib/mjs/migrations` are deliberately NOT in this list, even though
 * they are exactly such a build layout: they are the SAME source compiled twice into two module
 * formats, only one of which the running process can ever load - every package here ships
 * `"type": "module"` with no `package.json` written into `lib/cjs`, so Node parses `lib/cjs/*.js`
 * as ESM and a bare import of it throws (by design - see the `.js`-failure-throws comment below).
 * Scanning both unconditionally turned the sibling this runtime cannot load into a hard boot
 * failure the moment a package actually shipped both builds. `currentBuildMigrationDir()` below
 * picks the one that matches the current runtime instead, mirroring how
 * `@spinajs/configuration`'s `BaseFileSource` already picks ONE of its own dual-build config globs
 * off the same DI flag (`packages/configuration/src/sources.ts`).
 */
export declare const DEFAULT_MIGRATION_DIRS: string[];
/**
 * The one directory, of `lib/cjs/migrations` and `lib/mjs/migrations`, that the CURRENTLY RUNNING
 * process can actually import migrations from - see the comment on `DEFAULT_MIGRATION_DIRS` for
 * why the other one is never scanned at all rather than scanned-and-tolerated.
 */
export declare function currentBuildMigrationDir(): string;
/**
 * `env` ( normalized `process.env.APP_ENV` ) is interpolated straight into a glob pattern in
 * `FilesystemMigrationSource.getMigrations()` - a plain identifier-ish token only, so it cannot
 * carry glob metacharacters (`{`, `[`, `!`, `*`, a path separator, ...) into a pattern nobody wrote.
 */
export declare const SAFE_ENV_NAME_REGEXP: RegExp;
/**
 * Supplies migration types to `Orm`.
 *
 * Sources only DISCOVER migrations ( type + origin file ) - they never construct or run them.
 * `Orm` merges every registered source, resolves each migration's environment, dedupes and
 * registers what is left.
 *
 * To plug in another discovery mechanism ( a plugin manifest, a remote registry ) implement this
 * class and decorate it `@Injectable(MigrationSource)`.
 */
export declare abstract class MigrationSource extends AsyncService {
    abstract getMigrations(): Promise<Array<ClassInfo<OrmMigration>>>;
}
/**
 * Discovers migrations by scanning the directories configured at `system.dirs.migrations`.
 *
 * Two globs per directory: unsuffixed files, which belong to every environment, and files carrying
 * this environment's tag. Files belonging to another environment are never MATCHED, and therefore
 * never imported - which is the whole point rather than an optimization. Importing a migration
 * fires its `@Migration` decorator, which registers the class into `__migrations__`, and
 * `DiRegistryMigrationSource` would then hand it back no matter what filter ran afterwards.
 *
 * This is also why `@ListFromFiles` from `@spinajs/reflection` is not used here: it imports
 * everything it lists, and its glob is fixed at decoration time while the environment is only
 * known at runtime.
 */
export declare class FilesystemMigrationSource extends MigrationSource {
    protected Log: Log;
    protected Configuration: Configuration;
    getMigrations(): Promise<Array<ClassInfo<OrmMigration>>>;
}
/**
 * Discovers migrations registered in the DI container under `__migrations__` - which is what the
 * `@Migration` decorator does, so this covers every migration reached by IMPORT: a package
 * re-exporting its migrations from `index.ts`, a test declaring one inline, or a file this
 * process's `FilesystemMigrationSource` has just imported.
 *
 * The origin file is the path `@Migration` captured off the stack, and the sentinel
 * `MIGRATION_DI_SOURCE` when that capture came back empty.
 */
export declare class DiRegistryMigrationSource extends MigrationSource {
    getMigrations(): Promise<Array<ClassInfo<OrmMigration>>>;
}
//# sourceMappingURL=migration-sources.d.ts.map