/** * `ClassInfo.file` for a migration whose source file could not be determined - registered through * DI under a bundler that mangles stack paths. Such an entry has no suffix to read, so its * `@Migration({ Env })` option is its only env signal. */ export declare const MIGRATION_DI_SOURCE = ""; /** * The environment tag carried by a migration's FILE NAME, normalized, or `undefined` when it has * none. The tag is the single dot-segment between the class name and the extension - but a * filename only HAS a tag to read if it is a migration file in the first place, which the * convention already marks: its first dot-segment carries the `_yyyy_MM_dd_HH_mm_ss` timestamp * every migration class name is stamped with (`MIGRATION_FILE_REGEXP`). A filename whose first * segment doesn't carry that stamp isn't an environment-tagged migration file at all, so there is * no tag to read, no matter how many dots follow: * * Foo_2026_07_29_10_00_00.ts -> undefined ( every environment ) * Foo_2026_07_29_10_00_00.ts.js -> undefined ( .js is an unsuffixed compiled artifact ) * Foo_2026_07_29_10_00_00.local.ts -> 'local' * Foo_2026_07_29_10_00_00.local.js -> 'local' * Foo_2026_07_29_10_00_00.dev.ts -> 'dev' * Foo_2026_07_29_10_00_00.dev.js -> 'dev' * Foo_2026_07_29_10_00_00.test.ts -> undefined ( a test suite named after its migration, * carved out below - see its comment ) * Foo_2026_07_29_10_00_00.test.js -> undefined ( same, .js compiled artifact of test suite ) * Foo_2026_07_29_10_00_00.spec.ts -> undefined ( same, .spec naming convention ) * Foo_2026_07_29_10_00_00.spec.js -> undefined ( same, .js compiled artifact of spec suite ) * Foo_2026_07_29_10_00_00.test.cjs -> undefined ( same carve-out, cjs/mjs compiled artifacts ) * Foo_2026_07_29_10_00_00.spec.mjs -> undefined ( same ) * Foo_2026_07_29_10_00_00.d.ts -> undefined ( TypeScript declaration file ) * Foo_2026_07_29_10_00_00.d.js -> 'd' ( .d.js is not a declaration convention, * so 'd' is a legitimate environment name ) * migration.test.ts -> undefined ( 'migration' carries no timestamp ) * Bar.stories.ts -> undefined ( 'Bar' carries no timestamp ) * * This is what lets `@Migration`'s `SourceFile` - captured off the V8 stack, so it can be ANY file * that declares a migration, including a test suite living at `migration.test.ts` - be read safely * without a growing blocklist of exemptions for every dotted naming convention nobody thought of * yet (`.mock.ts`, `.stories.ts`, `.fixture.ts`, ...). * * Only the BASENAME is examined - a project living under `C:\my.app\v1.2\` would otherwise read * its directory names as environments. */ export declare function parseMigrationFileEnv(file: string): string | undefined; /** * The environment a single discovered migration belongs to, from its file name and its * `@Migration({ Env })` option. * * Both present and disagreeing throws rather than picking a winner: the two are the same * declaration written twice, so a contradiction is always a mistake, and silently choosing one * means the migration runs somewhere nobody intended. Comparison happens after normalization, so * `.dev.ts` plus `{ Env: 'development' }` agree. */ export declare function resolveMigrationEnv(name: string, file: string, decoratorEnv?: string): string | undefined; /** * The environment of two entries that turned out to be the same migration - the same class name * reached from two origins, which is the NORMAL case: `src/` and `lib/` hold the same class, and a * file discovered on disk is also registered through DI by the import that discovered it. * * An absent env is not a vote and never conflicts, because the DI entry for a discovered * `.local` file carries no suffix - letting it "win" by arriving first would drop the tag and run * the migration everywhere. Two DIFFERENT envs are a genuine contradiction and throw. */ export declare function mergeMigrationEnv(name: string, a: { env?: string; file: string; }, b: { env?: string; file: string; }): string | undefined; //# sourceMappingURL=migration-environment.d.ts.map