import { type SettingsStore } from './settingsStore.js';
export interface XppConfig {
    /** Filename without .json, e.g. "contoso-dev___10.0.2428.63" */
    fullName: string;
    /** Environment name before the ___ separator */
    name: string;
    version: string;
    file: string;
    mtimeMs: number;
    modelStoreFolder?: string;
    frameworkDirectory?: string;
}
export declare function xppConfigDir(): string | null;
/** All versioned configs, newest first. Empty when the directory is absent. */
export declare function listXppConfigs(): XppConfig[];
/**
 * The full {@link XppConfig} a UDE target resolves to: the pinned one, or the
 * newest available when nothing is pinned. Null for a traditional target, when
 * no config exists at all, and — deliberately — when the pin names a config
 * that is gone.
 *
 * Mirrors XppConfigProvider.getActiveConfig exactly, including that last case:
 * it matches either form of the name and returns null rather than substituting
 * a different environment. A pin that no longer resolves is the
 * stale-after-UDE-upgrade state isXppConfigStale() flags and `instance upgrade`
 * exists to fix; answering it with the newest config would have a caller
 * extract from 10.0.2500 and stamp the result as this target's, while its index
 * and server still reference the old pin.
 */
export declare function resolvePinnedXppConfig(store: SettingsStore): XppConfig | null;
/**
 * Is this target a UDE target at all — i.e. does a null from
 * {@link resolvePinnedXppConfig} mean "its pin does not resolve" rather than
 * "this is a traditional install"?
 *
 * That function returns null for three different reasons and a caller cannot
 * tell them apart, which matters because the two answers call for opposite
 * behaviour: a traditional target legitimately falls back to detecting the
 * packages root on this box, while for a UDE target that fallback throws away
 * the very guarantee the null was there to provide (see resolveSource in
 * commands/bpCatalog.ts, and the docblock above).
 *
 * Mirrors the detection settings.ts documents for an unset environment.type:
 * UDE when XPP config files exist in %LOCALAPPDATA%\Microsoft\Dynamics365\
 * XPPConfig. So a box with no configs at all is traditional — the one case
 * where falling through is correct — and anything else with an explicit
 * `traditional` type is taken at its word.
 */
export declare function isUdeTarget(store: SettingsStore): boolean;
/**
 * Expand a short config name (e.g. "myenv-dev") to the newest full versioned
 * name ("myenv-dev___10.0.2345.153") so a later staleness check is a plain
 * file-exists test, and persist the expansion. No-op for traditional
 * environments, full names, or when nothing matches.
 * Returns the expansion that happened, or null.
 */
export declare function normalizeXppConfigName(store: SettingsStore): {
    from: string;
    to: string;
} | null;
/**
 * True when the pinned config name no longer resolves to a file — i.e. the UDE
 * was upgraded since the instance was configured and its database is stale.
 * Only meaningful after normalizeXppConfigName.
 */
export declare function isXppConfigStale(store: SettingsStore): boolean;
//# sourceMappingURL=xppConfig.d.ts.map