import { FoldLine, FoldableRange, Indentation, LineRange, SupportedLanguage } from "@ngrok/mantle/highlight-utils";
import { createHighlighter } from "shiki";
import "oxc-parser";
/**
 * Shiki grammar IDs preloaded by Mantle's highlighting engine.
 * This list is shared by both Vite plugins and server-side highlighting routes.
 */
declare const mantleShikiLanguageGrammarIds: ["bash", "csharp", "css", "dotenv", "go", "html", "java", "javascript", "json", "jsx", "python", "ruby", "rust", "shell", "terraform", "tsx", "typescript", "xml", "yaml"];
/**
 * Shared Shiki theme name used across Mantle highlighting.
 */
declare const mantleShikiThemeName: "mantle-css-variables";
declare const mantleHighlightCacheMaxEntries = 1000;
type ShikiHighlighter = Awaited<ReturnType<typeof createHighlighter>>;
type MantleHighlightInput = {
  /**
   * Raw code string to highlight.
   */
  code: string;
  /**
   * Language hint. Accepts supported language aliases and markdown-style values.
   */
  language: SupportedLanguage | (string & {});
  /**
   * Optional indentation preference. Defaults to language-inferred indentation.
   */
  indentation?: Indentation;
  /**
   * Whether to render line numbers into the returned HTML.
   * @default true
   */
  showLineNumbers?: boolean;
  /**
   * Optional list of highlighted line numbers/ranges to render into the returned HTML.
   * @default []
   */
  highlightLines?: (LineRange | number)[];
  /**
   * Start line number for rendered line numbers.
   * @default 1
   */
  lineNumberStart?: number;
};
type MantleHighlightResult = {
  /**
   * Normalized source code used as the highlight input.
   */
  code: string;
  /**
   * Highlighted HTML extracted from Shiki's `<code>...</code>`.
   */
  html: string;
  /**
   * Resolved supported language used for highlighting.
   */
  language: SupportedLanguage;
  /**
   * Whether returned HTML includes line numbers.
   */
  showLineNumbers: boolean;
  /**
   * Highlighted line numbers/ranges applied to the returned HTML.
   */
  highlightLines: (LineRange | number)[];
  /**
   * Start line number used for rendered line numbers.
   */
  lineNumberStart: number;
};
type MantleServerHighlighter = {
  /**
   * Highlight a code snippet and return normalized code + highlighted HTML.
   */
  highlight: (input: MantleHighlightInput) => Promise<MantleHighlightResult>;
};
/**
 * Creates (and caches) Mantle's shared Shiki highlighter instance.
 */
declare function getMantleShikiHighlighter(): Promise<ShikiHighlighter>;
/**
 * Highlights code with Mantle's shared Shiki engine and normalization defaults.
 */
declare function highlightWithMantleShiki(input: MantleHighlightInput): Promise<MantleHighlightResult>;
/**
 * Creates a reusable Mantle server highlighter facade for API routes.
 */
declare function createMantleServerSyntaxHighlighter(): MantleServerHighlighter;
/**
 * Server-side folding strategy applied to a language. This is a richer
 * dispatch than `@ngrok/mantle/highlight-utils`'s `foldStrategyFor`:
 *
 * - `jsx-ast` parses JS / TS / JSX / TSX with `oxc-parser`.
 * - `html-ast` parses HTML / XML with `parse5`.
 * - `css-raw` runs a CSS-aware single-pass brace matcher.
 * - `json-raw` reuses the existing `computeJsonFoldRanges` (raw, scope-free).
 * - `token-bracket` / `token-indentation` are the existing token-based
 *   strategies for languages without a heavier parser (Go, Rust, Java, C#,
 *   Python, YAML).
 * - `token-keyword` matches keyword openers / closers against tokenized line
 *   text (Bash / Shell).
 * - `token-bracket-and-keyword` runs the bracket pass *and* the keyword pass
 *   and merges them — Ruby uses brace-style blocks (`{ |x| … }`) plus
 *   keyword blocks (`def … end`).
 * - `none` opts out for plain text and unknown languages.
 *
 * Strategies suffixed `-ast` or `-raw` need only the raw source string;
 * `token-*` strategies need Shiki-tokenized lines with scope explanations.
 */
type ServerFoldStrategy = "jsx-ast" | "html-ast" | "css-raw" | "json-raw" | "token-bracket" | "token-indentation" | "token-keyword" | "token-bracket-and-keyword" | "none";
/** Returns the server fold strategy for the given supported language. */
declare function serverFoldStrategyFor(language: SupportedLanguage): ServerFoldStrategy;
/**
 * Returns true when the strategy needs Shiki-tokenized lines (with scope
 * explanations) to run. AST and raw-source strategies operate on the source
 * string directly and let us skip the `includeExplanation: 'scopeName'`
 * Shiki option, saving meaningful work on JS/TS/HTML/CSS hot paths.
 */
declare function serverFoldNeedsTokens(strategy: ServerFoldStrategy): boolean;
/**
 * Computes foldable ranges for a single highlighted code block, dispatching
 * to the appropriate strategy. Every supported language flows through here,
 * including the legacy token-based ones, so the engine has a single decision
 * point.
 *
 * Caller contract:
 * - For token-needing strategies, `tokens` must be the lines produced by
 *   Shiki with `includeExplanation: 'scopeName'`. Pass `undefined` and the
 *   strategy returns `[]`.
 * - For raw / AST strategies, `tokens` is ignored; only `code` matters.
 *
 * Errors raised by underlying parsers are caught and converted into "no
 * folds" — Shiki still gets to render the highlighted code, the gutter just
 * skips the toggle. We log nothing here because the engine is the wrong
 * layer to surface diagnostics.
 */
declare function computeServerFoldRanges({ code, language, tokens }: {
  /** Normalized source code (post-`normalizeIndentation`). */
  code: string;
  /** Resolved Mantle supported language. */
  language: SupportedLanguage;
  /** Shiki-tokenized lines, when the strategy needs them. */
  tokens: FoldLine[] | undefined;
}): FoldableRange[];
/**
 * AST-based fold computer for the JS/TS/JSX/TSX language family.
 *
 * Mirrors VS Code's TypeScript language service folder by walking the parsed
 * AST instead of pairing brackets in the token stream. This lets us fold
 * constructs that bracket-pairing can't see:
 *
 * - JSX elements (`<Foo>…</Foo>`, fragments, members like `<obj.Foo>`).
 * - Template literals that span multiple lines (including tagged templates).
 *
 * It also keeps every fold the bracket strategy used to give us — block
 * statements, object literals, array literals, class/interface bodies, switch
 * statements — without the per-character scope-walk cost.
 *
 * @see https://github.com/microsoft/vscode/blob/main/extensions/typescript-language-features/src/languageFeatures/folding.ts
 */
/** Subset of supported languages handled by this computer. */
type JsxFoldLanguage = "javascript" | "js" | "typescript" | "ts" | "jsx" | "tsx";
/**
 * Computes foldable ranges for a JS/TS/JSX/TSX source string by parsing it
 * with `oxc-parser` and walking the AST. Errors are tolerated — a partial AST
 * still produces useful folds.
 *
 * @example
 * computeJsxFoldRanges({ code: "<Foo>\n  <Bar/>\n</Foo>", language: "tsx" });
 * // => [{ id: "1", startLine: 1, endLine: 3 }]
 */
declare function computeJsxFoldRanges({ code, language }: {
  /** Raw source code to parse and fold. */
  code: string;
  /** Resolved Mantle language; controls grammar selection (TS vs JS, JSX vs plain). */
  language: JsxFoldLanguage;
}): FoldableRange[];
/**
 * AST-based fold computer for HTML and XML.
 *
 * Uses `parse5` with `sourceCodeLocationInfo: true` so each element node carries
 * the line numbers of its open and close tags. Walking the tree gives us:
 *
 * - One fold per multi-line element (`<div>…</div>`).
 * - One fold per multi-line opening tag (`<div\n  class="x"\n>` — the
 *   attribute list collapses).
 * - Correct void-element handling — parse5 already knows that `<br>`, `<img>`,
 *   etc. don't open folds.
 * - Template content traversal — parse5 stores `<template>` descendants on a
 *   separate `content` fragment, not on `childNodes`.
 * - String/comment scope filtering — angle brackets in `<!-- … -->` or
 *   inside `"…"` attribute values aren't mistaken for tag openings.
 *
 * @see https://parse5.js.org/
 */
type HtmlFoldLanguage = "html" | "xml";
/**
 * Computes foldable ranges for an HTML or XML source string.
 *
 * - HTML: uses `parse5.parse` so explicit `<html>`/`<head>`/`<body>` are
 *   honored as foldable openers. Implicit wrappers parse5 fabricates for
 *   fragment input have no `sourceCodeLocation` and are skipped.
 * - XML: uses `parse5.parseFragment` rooted in an SVG fragment context so the
 *   tokenizer applies foreign-content (XML-like) rules — self-closing `<foo/>`
 *   is respected, void HTML elements aren't special-cased.
 *
 * @example
 * computeHtmlFoldRanges({ code: "<div>\n  <p>hi</p>\n</div>", language: "html" });
 * // => [{ id: "1", startLine: 1, endLine: 3 }]
 */
declare function computeHtmlFoldRanges({ code, language }: {
  /** Raw source code to parse. */
  code: string;
  /** Resolved Mantle language; selects HTML vs. XML parsing rules. */
  language: HtmlFoldLanguage;
}): FoldableRange[];
/**
 * Raw-source fold computer for CSS — single-pass, parser-quality without a
 * parser dependency.
 *
 * Mirrors `computeJsonFoldRanges` but adds CSS-specific lexical features:
 *
 * - `/* … *​/` block comments are skipped wholesale.
 * - `"…"` and `'…'` string literals (including `\\` and `\` escapes) are
 *   skipped so braces inside `content: "{ }"` don't open folds.
 * - Backslash escapes outside of strings (CSS identifiers can use them) are
 *   transparent — we just consume the next character.
 *
 * lightningcss is the project's preferred CSS parser, but its public visitor
 * API only surfaces *start* locations (`Location { line, column }`), not end
 * locations, which is what `FoldableRange.endLine` requires. Until upstream
 * exposes end spans we get the same correctness from a single-pass brace
 * matcher with a tiny CSS lexer — and skip the ~5MB native dep.
 *
 * @see https://github.com/parcel-bundler/lightningcss/issues/512
 */
/**
 * Computes foldable ranges for a CSS source string. Each multi-line `{ … }`
 * (style rule, at-rule body, nested rule, keyframe selector) emits one range
 * with the opener and closer lines staying visible.
 *
 * Tolerant of malformed CSS — unmatched braces are dropped silently rather
 * than throwing, so a partial snippet still gets every fold it can. This
 * matches the behavior of `computeJsonFoldRanges` for JSON.
 *
 * @example
 * computeCssFoldRanges({ code: ".a {\n  color: red;\n}" });
 * // => [{ id: "1", startLine: 1, endLine: 3 }]
 */
declare function computeCssFoldRanges({ code }: {
  /** Raw CSS source code to scan. */
  code: string;
}): FoldableRange[];
/**
 * Keyword-pair fold computer for languages whose blocks are delimited by
 * keywords rather than punctuation.
 *
 * VS Code models this with `foldingStartMarker` / `foldingStopMarker`
 * declarations in each language's `language-configuration.json`. We mirror
 * that behavior with linear marker predicates, evaluated against the
 * *visible* (non-string, non-comment) portion of each line — the Shiki tokens
 * carry scope information that lets us strip those out reliably.
 *
 * The stack is untyped — every closer pops the most recent opener, regardless
 * of which keyword opened it. Real source code nests properly, so this stays
 * correct without per-keyword tracking, and matches VS Code's marker-based
 * behavior.
 *
 * @see https://github.com/microsoft/vscode/blob/main/extensions/ruby/language-configuration.json
 * @see https://github.com/microsoft/vscode/blob/main/extensions/shellscript/language-configuration.json
 */
/** Languages this computer knows how to fold. */
type KeywordFoldLanguage = "ruby" | "rb" | "bash" | "sh" | "shell";
/**
 * Computes foldable ranges from tokenized source lines using the language's
 * keyword opener/closer regex pair.
 *
 * The same line can both open and close a block (`if foo; end` in Ruby).
 * Such lines push and pop on the stack but their start/end coincide, so the
 * range gets discarded by the `endLine > startLine` filter — matching how
 * the bracket strategy treats single-line `{}` constructs.
 *
 * @example
 * // tokens: [["def f"], ["  pass"], ["end"]]
 * computeKeywordFoldRanges({ language: "ruby", tokens });
 * // => [{ id: "1", startLine: 1, endLine: 3 }]
 */
declare function computeKeywordFoldRanges({ language, tokens }: {
  /** Resolved Mantle language; controls which keyword pattern to use. */
  language: KeywordFoldLanguage;
  /** Shiki-tokenized lines, with scope explanations populated. */
  tokens: FoldLine[];
}): FoldableRange[];
export { type HtmlFoldLanguage, type JsxFoldLanguage, type KeywordFoldLanguage, type MantleHighlightInput, type MantleHighlightResult, type MantleServerHighlighter, type ServerFoldStrategy, computeCssFoldRanges, computeHtmlFoldRanges, computeJsxFoldRanges, computeKeywordFoldRanges, computeServerFoldRanges, createMantleServerSyntaxHighlighter, getMantleShikiHighlighter, highlightWithMantleShiki, mantleHighlightCacheMaxEntries, mantleShikiLanguageGrammarIds, mantleShikiThemeName, serverFoldNeedsTokens, serverFoldStrategyFor };
//# sourceMappingURL=index.d.ts.map