/**
 * What {@link pruneStaleCompilerMetadata} did to one package's XppMetadata tree.
 * Paths are the XppMetadata files removed, so the build log can name them.
 */
export interface CompilerMetadataPruneResult {
    /** Files whose source changed after they were written; the source was touched so xppc recompiles it. */
    stale: string[];
    /** Files whose source no longer exists — nothing would ever rewrite or remove them. */
    phantoms: string[];
    /** Model folders left alone because the package has no source for them (a binary-only deployment). */
    skippedModels: string[];
    /** Non-fatal per-file problems; the file is left as it was. */
    errors: string[];
    /** Metadata files examined. */
    scanned: number;
}
/**
 * Remove the compiler-metadata files an incremental build would otherwise leave stale.
 *
 * xppc's "Metadata Write-Back" rewrites `<compilermetadata>\<Package>\XppMetadata\<Model>\<AxType>\<Name>.xml`
 * when an element GAINS something, but not when it loses something. Measured on 7.0.7996.33, with
 * `-incremental`: a field removed from a class stays declared in its XppMetadata file, while a field
 * renamed is written back correctly; a deleted class keeps its file forever. `RuntimeMetadataWriter`
 * serializes that tree into the `.md` manifests (see generateMetadata.ts), so the deployed package
 * declares members its IL no longer has — under a green build. A full build clears the whole tree
 * first (removeModelCompilerMetadata); an incremental build cannot, because xppc then writes back
 * only the elements it recompiles and every unchanged element would vanish from the metadata.
 *
 * So this works per file, on the one signal that is sound: a stale file is never rewritten, so its
 * mtime is older than its source's.
 *
 *  - Source newer than the metadata file → delete the file AND touch the source. The touch is not
 *    optional. xppc decides what to recompile from the source mtime against its own baseline (an
 *    edit with the mtime pinned back is not compiled at all), so a change that an earlier build
 *    already compiled — a Visual Studio build, or one from before this fix — is no longer "changed"
 *    to xppc. Deleting its metadata without the touch makes the element disappear from the
 *    metadata instead of refreshing it. With the touch it is recompiled and written back, and that
 *    holds even when it fails to compile (the write-back still runs, and the element stays
 *    "changed" for the next build). If the touch fails, the file is kept — stale beats missing.
 *  - Source gone → delete the file. Nothing else will.
 *  - Model folder with no source at all → leave the whole model alone; that is a package deployed
 *    without source, and its metadata is the only copy.
 *
 * A census of all 109,672 XppMetadata files on a UDE box found no element whose metadata path
 * differed from its source path; the only files without a source (58) were genuinely deleted
 * elements. A false "newer" (a git checkout that rewrote an unchanged file) costs one recompile of
 * that element and nothing else: after the build the metadata is newer again.
 */
export declare function pruneStaleCompilerMetadata(compilerMetadataRoot: string, sourceRoot: string, packageName: string): Promise<CompilerMetadataPruneResult>;
//# sourceMappingURL=compilerMetadataPrune.d.ts.map