/**
 * Source Map Optimizer
 *
 * This module optimizes source maps generated by the Botpress CLI (`bp dev` and `bp build`)
 * by removing sources that fall outside the agent's src directory.
 *
 * ## Problem
 * The bundled bot includes source maps that reference ALL sources, including:
 * - Agent's own code (~10 files)
 * - All node_modules dependencies (~10,000+ files)
 * - Botpress SDK internals
 *
 * This results in source maps that are 30+ MB, where 99% of the content is from
 * dependencies the user doesn't care about when debugging their agent.
 *
 * ## Solution
 * 1. Parse the source map and identify which sources are inside the agent's src directory
 * 2. Decode the VLQ mappings in a single pass, retaining only the segments that
 *    reference a kept source (plus generated-column-only markers)
 * 3. Re-encode the (tiny) retained set with compacted source/name indices
 * 4. Save both an optimized .map file AND inline it into the .cjs bundle
 *
 * ## What is VLQ?
 * Variable Length Quantity (VLQ) is a compact encoding format used in source maps.
 * Source maps use VLQ to encode the "mappings" string, which contains information about
 * how each position in the generated code maps back to the original source.
 *
 * Each segment in the mappings can contain up to 5 fields (all VLQ-encoded):
 * 1. Column position in the generated code
 * 2. Source file index (into the sources array)
 * 3. Line number in the original source
 * 4. Column position in the original source
 * 5. Name index (into the names array) - optional
 *
 * The mappings string uses:
 * - `;` to separate lines
 * - `,` to separate segments within a line
 * - Base64 characters to encode VLQ values
 *
 * ## Performance
 * The decode is unavoidable — source/name indices are cumulative deltas, so every
 * segment must be decoded to keep the running state correct even for the ~99% that
 * get dropped. But we avoid the two dominant costs of a naive decoder: we never
 * allocate a tuple per VLQ field (a shared cursor is advanced in place), and we
 * only materialize an object for segments we actually keep. For an agent bundle
 * that turns millions of allocations into thousands.
 */
export interface SourceMapOptimizeOptions {
    /**
     * Path to the source map file (.cjs.map)
     */
    sourceMapPath: string;
    /**
     * Path to the agent's src directory.
     * Sources outside this directory will be removed.
     */
    agentSrcPath: string;
}
/**
 * Optimizes a source map by removing sources that fall outside
 * the agent's src directory and rebuilding the mappings.
 *
 * This dramatically reduces the size of the source map (typically 90%+ reduction)
 * without losing valuable debugging information for the agent's own code.
 *
 * The optimized source map is both:
 * 1. Written to the .map file (for external reference)
 * 2. Inlined as base64 into the .cjs bundle (for runtime debugging)
 *
 * We inline the source map because after optimization it's tiny (usually <1MB),
 * which makes it much easier for tools like VSCode and Chrome DevTools to load
 * and use for debugging. Inline source maps eliminate the need for additional
 * HTTP requests or file system lookups, providing instant source mapping.
 *
 * @param options - Configuration options
 * @returns Promise that resolves when the source map has been optimized
 */
export declare function optimizeSourceMap(options: SourceMapOptimizeOptions): Promise<void>;
//# sourceMappingURL=source-map-optimizer.d.ts.map