import { Plugin } from 'vite';
import { CompilerContext } from '../context/index.ts';
/**
 * CSS extension list taken from https://github.com/vitejs/vite/blob/a8c7083a3d7d7fe2e83e994ff008f39ee4f298f8/packages/vite/src/node/constants.ts#L50
 */
export declare const cssLangsRe: RegExp;
/**
 * A flag added by Lumina at compile time to named CSS imports to turn
 * them into Lit css`` tagged template literals (using `styles` named import).
 *
 * We do not automatically process every CSS file to allow for both:
 * - keeping side-effect CSS imports inside external library code as is
 *   - tricky to do using resolveId() because ESBuild is used for some files in
 *     dev server.
 * - explicitly importing external library's CSS as Lit css into shadow root
 *   - example: monaco or ckeditor styles, but attached into shadow root, rather
 *     than global
 */
export declare const litCssFlag = "?litCss";
/**
 * The `.adoptedStyleSheets` API is very convenient, but it has one issue: it
 * has higher precedence order than the `<link>` or `<style>` tags. This API was
 * designed with apps in mind, not libraries.
 *
 * As a workaround, we are wrapping the CSS in a `@layer {}` syntax to reduce
 * it's precedence.
 *
 * More information:
 * https://discord.com/channels/1012791295170859069/1274527043614150708
 */
export declare const layeredLitCssFlag = "?layeredLitCss";
/**
 * Vite's library mode has CSS support (https://vite.dev/guide/build.html#css-support).
 * However, if global css file references assets, the library mode will insert
 * the assets base path in the CSS file. This does not work for us since the
 * asset path is determined at runtime - provided by the user.
 *
 * Additionally, Vite's library mode css handling does not quite fit our use case:
 * - We need to transform the global CSS to add hydrate CSS
 *   - Trickier given that we need to emit hydrate CSS even if user did not
 *     provide global css
 * - Vite has css chunking support, which we don't need
 * - We need to add an import for our CSS file (and those of libraries we are
 *   consuming) in runtime.ts, without processing the external CSS files
 *
 * It is possible to make Vite's library mode css work, but requires too much
 * effort. Instead, we are bypassing Vite's global CSS handling and doing the
 * simple handling sufficient for our single global css file:
 * - During build, we insert a import into the loader.ts file purely
 *   so that the transform() is triggered for that file so that we can piggy back
 *   on the transformed output (and create a separate .css file out of it).
 *   Such import has no side-effects and is removed by Rollup.
 *
 *   This is the only way to trigger the CSS transform without getting it added
 *   to the bundle because of this Vite behavior:
 *   https://github.com/vitejs/vite/pull/11469#:~:text=Further%2C%20this.load%20is%20supposed%20to%20trigger%20transform%20and%20moduleParsed%20%2D%20this%20does%20not%20(in%20accordance%20with%20vite%27s%20on%2Ddemand%20nature
 * - We manually write dist/main.css based on hydrate CSS and global CSS.
 * - During generateBundle() stage, we transform the emitted chunks/runtime.js
 *   to add the import to global CSS for our library and web component libraries
 *   we are consuming. We do this in generateBundle() stage so that such imports
 *   are not processed by bundler. Additionally, our loadLitCss plugin's
 *   transform() has a detection of side-effect CSS imports to error for them
 *   saying they should be import as named to be added to the shadow root - by
 *   doing this in generateBundle(), we bypass that check.
 */
export declare const globalCssFileFlag = "?globalFileLitCss";
/**
 * Given a CSS file like:
 *
 * ```css
 * // counter.css
 * :host {
 *   display: flex;
 *   gap: 1rem;
 * }
 * button {
 *   padding: 1rem;
 * }
 * ```
 *
 * and an import like this:
 *
 * ```ts
 * import styles from './counter.css';
 * export class ArcgisCounter extends LitElement {
 *  static override styles = [styles];
 * }
 * ```
 *
 * This plugin will tell Vite to inline the css file (rather than produce a
 * separate asset). Vite transformer will transform the css file into this:
 *
 * ```js
 * export default ":host{display:flex;gap:1rem}button{padding:1rem}"
 * ```
 *
 * Then, we augment it into this:
 * ```js
 * import { css } from 'lit/css-tag.js';
 * const styles = css`:host{display:flex;gap:1rem}button{padding:1rem}`;
 * export default styles;
 * ```
 *
 * The Lumina runtime later loads it like this:
 *
 * ```js
 * host.adoptedStyleSheets = [...document.adoptedStyleSheets, styles.styleSheet];
 * // Host is the shadow root of the component for shadow root components. Host
 * // is the document for non-shadow root components or global styles.
 * ```
 *
 * @remarks
 * We inline the css rather than produce a separate asset because:
 * - Loading assets adds complexity:
 *   - need to call getAssetPath() to get correct asset location
 *     (can't do that easily in a .css file)
 *   - the consuming application might not have had the chance to call
 *     setAssetPath() yet when getAssetPath() is called by us
 *   - the network request might fail
 * - Loading assets creates "a flash of unstyled content" issue (i.e font
 *   changing after being loaded)
 *
 * Same goes for assets references inside the css file (icons and fonts) - they
 * will be inlined as base64 to simplify our life.
 */
export declare const loadLitCss: (context: CompilerContext) => Plugin;
export declare function viteCssModuleToLit(code: string, withHmr: boolean, minify: boolean, isLayered: boolean): string;