@arcgis/lumina-compiler 5.2.0-next.2 → 5.2.0-next.21

package/dist/jsxToLitHtml/inferPropType.d.ts

@@ -1,40 +0,0 @@
-import { default as ts } from 'typescript';
-import { dynamicHtmlSymbol, dynamicSvgSymbol } from './config.ts';
-/**
- * Check if prop initializer has bindProperty(), bindAttribute(),
- * bindBooleanAttribute() or bindEvent() call - these explicitly indicate the
- * prop type.
- *
- * @remarks
- * Not checking for now if function is actually coming from `@arcgis/lumina` - if
- * this is an issue, can add later
- */
-export declare function checkExplicitPropType(initializer: ts.JsxAttributeValue | undefined): {
-    readonly propType: JsxPropType;
-    readonly initializer: ts.JsxExpression | undefined;
-} | undefined;
-/**
- * Decide whether a JSX prop should be converted to property, attribute or event
- *
- * Unless there is a good reason to do otherwise, most props are converted into
- * properties rather than attributes. Reasons:
- * - For third-party web components, since we are consuming them in JSX, the
- *   typings will most likely include names of properties not attributes.
- * - Setting attributes is more bug-prone in lit as `a=${undefined}` is still
- *   considered truthy (you have to use `a=${nothing}` to unset an attribute)
- *   - If you want to conditionally display a boolean html attribute, there is
- *     the `?a=${someBoolean}` syntax.
- *   - The above two cases add complexity and bugs - properties are much simpler
- * - Setting property is more performant than setting attribute
- *
- * For most HTML attributes, setting the property will reflect to the attribute.
- * If the third-party web component expects to have the attribute set (for
- * styling or other reasons), it should reflect the property.
- * There are also flag functions available (bindAttribute and etc) if you
- * explicitly want to overwrite the below prop type inference logic.
- */
-export declare function inferPropType(propName: string, initializer: ts.JsxAttributeValue | undefined, tagName: string | typeof dynamicHtmlSymbol | typeof dynamicSvgSymbol): JsxPropType;
-declare const specialPropsArray: readonly ["class", "style", "ref", "directives", "key", "deferLoad"];
-type SpecialProp = (typeof specialPropsArray)[number];
-export type JsxPropType = SpecialProp | "attribute" | "booleanAttribute" | "event" | "property";
-export {};

package/dist/jsxToLitHtml/insertRepeatCall.d.ts

@@ -1,51 +0,0 @@
-import { default as ts } from 'typescript';
-import { JsxContext } from './types.ts';
-/**
- * By default, when we see a `key=""` prop, we convert it like this:
- * ```tsx
- * // before:
- * <div key="value" />
- * // after:
- * keyed('value', html`<div></div>`);
- * ```
- *
- * However, when mapping over items, if key was provided, using `repeat()` Lit
- * directive is better for performance as that directive can track when items
- * change order.
- *
- * Without repeat, calling `keyed()` inside of `.map()` is going to be quite
- * expensive when a single item is added to the top - that will destroy each
- * element below it and re-create it.
- *
- * When key wasn't provided, we assume that the order of items is static or that
- * modifying the item dom node is cheaper than getting the key and reordering.
- *
- * We could have the Stencil to Lit codemod do the `.map()` to `repeat()`
- * conversion in cases when the map was given an arrow function with a JSX
- * element with a key, however, some issues with that:
- *
- * - For people coming from Stencil or React, it would be confusing to see
- *   `repeat()` in the code rather than the familiar `.map()`.
- * - People may not know when to use which, or forget and use `.map()` with a
- *   `key` inside.
- * - Since many JSX frameworks handle `key` inside a `.map()` correctly, if in
- *   the future we move from Lit, it would be nice to have the `key` prop
- *   already in the source code.
- *
- * Thus, instead of doing the conversion in the codemod, I am doing it at build
- * time in the _JSX to lit-html_ transformer.
- *
- * If we were to do this in the codemod, the same code would have to be written
- * anyway, but here we get ongoing benefit of having code always using the
- * correct, performant pattern.
- *
- * We are only replacing `.map()` with `repeat()` if the map JSX element has a
- * key prop. There may be some more complex patterns where key was used that we
- * can't yet detect - those may have worse performance, but the developer can
- * always call `repeat()` manually.
- *
- * @see https://github.com/lit/lit.dev/issues/1351
- */
-export declare function maybeInsertRepeatCall(context: JsxContext, node: ts.CallExpression): ts.CallExpression;
-export declare const unwrapExpression: <T extends ts.Node>(expression: T) => T | ts.Expression;
-export declare const isLiftedKey: (name: ts.JsxAttributeName, context: JsxContext) => boolean;

package/dist/jsxToLitHtml/jsxVisitor.d.ts

@@ -1,15 +0,0 @@
-import { default as ts } from 'typescript';
-import { TemplatePart } from './templateParts.ts';
-import { JsxContext } from './types.ts';
-/**
- * Recursively traverse the entire AST top-down, converting JSX to lit-html.
- */
-export declare function jsxVisitor<Type extends ts.Node = ts.Node>(context: JsxContext, 
-/**
- * Only provide this if the node is in a place where we have to guard against
- * rendering "false" to the screen (as lit-html as an anti-feature of
- * rendering booleans as strings rather than ignoring them)
- */
-parent: ts.Node | undefined, node: Type): Type;
-export declare const findKeyPropertyIndex: (jsxElement: ts.JsxOpeningElement | ts.JsxSelfClosingElement) => number;
-export declare function jsxExpressionToTemplateParts(context: JsxContext, jsxExpression: ts.JsxExpression, parent: Parameters<typeof jsxVisitor>[1]): [] | [TemplatePart];

package/dist/jsxToLitHtml/templateParts.d.ts

@@ -1,17 +0,0 @@
-import { default as ts } from 'typescript';
-import { JsxContext, LitTag, ambiguousSvgTag } from './types.ts';
-/**
- * Template part is a convenient intermediate representation for template
- * literal expressions.
- *
- * String template literal parts will be joined together, and expressions will
- * be put inside of `${}`.
- */
-export type TemplatePart = ts.Expression | string;
-export type JsxHostTemplateParts = {
-    readonly key: ts.Expression | undefined;
-    readonly parts: TemplatePart[];
-    readonly litTag: LitTag | typeof ambiguousSvgTag | undefined;
-};
-export declare const isNonEmptyTemplatePart: (part: TemplatePart) => boolean;
-export declare function templatePartsToLitExpression({ key, parts, litTag }: JsxHostTemplateParts, context: JsxContext): ts.Expression;

package/dist/jsxToLitHtml/throwOnImportingExternalized.d.ts

@@ -1,10 +0,0 @@
-import { JsxContext } from './types.ts';
-/**
- * Throw if encountered an explicit non-type-only import for a Calcite component
- * or some `@arcgis/*` component package - such packages should be externalized,
- * so there should not be explicit imports from them (otherwise, they would get
- * bundled in)
- *
- * If there are exceptions to this rule, please notify Lumina maintainers.
- */
-export declare function throwOnImportingExternalized(context: JsxContext): [];

package/dist/jsxToLitHtml/types.d.ts

@@ -1,74 +0,0 @@
-import { default as ts } from 'typescript';
-import { ResolvedDependencyComponents } from '../dependencies/discover.ts';
-import { CompilerContext } from '../context/index.ts';
-export type JsxContext = {
-    readonly compiler: CompilerContext;
-    /** Source file before the _JSX to lit-html_ transformation */
-    readonly sourceFile: ts.SourceFile;
-    readonly transformationContext: ts.TransformationContext;
-    /**
-     * All encountered native HTML elements and custom-elements along with a
-     * reference to a TypeScript JSX node where first occurrence was. You can use
-     * the TypeScript node to find the location where component was declared and
-     * thus inform what import paths need to be added in the current file.
-     *
-     * If you successfully resolved some element from this map, then please
-     * remove it from the map to not confuse any following resolvers.
-     */
-    readonly customElementsToImport: Set<string>;
-    readonly customElementsToImportDeferred: Set<string>;
-    /**
-     * Existing imported modules.
-     *
-     * If original specifier was for an external package, this will include the
-     * specifier as is.
-     *
-     * If original specifier was to a relative file, the path will be resolved
-     * to an absolute path, but without a file extension.
-     *
-     * Can be used to inform what custom elements are already imported
-     */
-    readonly existingImportedModules: Set<string>;
-    /**
-     * A set of absolute paths to modules in the current package from which the
-     * current file imported capitalized identifiers (capitalized identifier is
-     * often a functional component, though not always)
-     */
-    readonly importedFunctionComponentsFromModules: Set<string>;
-    readonly existingLitImports: Set<JsxImportName>;
-    /**
-     * If there already is an identifier with a given name in the class, rename
-     * the imported identifier to avoid conflicts.
-     */
-    readonly importRenames: Record<JsxImportName, string>;
-    readonly neededImports: Set<JsxImportName>;
-    readonly externalComponents: ResolvedDependencyComponents["components"];
-    readonly localComponents: ResolvedDependencyComponents["components"];
-    /**
-     * `key={}` attributes that were converted to `repeat()` calls and thus should
-     * not be converted to `keyed()` directives.
-     */
-    readonly liftedKeys: Set<ts.JsxAttributeName>;
-    readonly isInLightDomComponent: boolean;
-    hasNonLuminaJsxImport: boolean;
-};
-/**
- * Funny that lit called the "dynamic html" version of "html" as "staticHtml"
- */
-export declare const staticHtmlTag = "staticHtml";
-export declare const staticSvgTag = "staticSvg";
-export declare const htmlTag = "html";
-export declare const svgTag = "svg";
-export declare const ambiguousSvgTag: unique symbol;
-export declare const cssTag = "css";
-export declare const mathMlTag = "mathml";
-declare const litTagsArray: readonly ["css", "html", "mathml", "staticHtml", "staticSvg", "svg"];
-export declare const litTags: Set<"html" | "svg" | "css" | "mathml" | "staticHtml" | "staticSvg">;
-export type LitTag = (typeof litTagsArray)[number];
-export declare const jsxImportNames: readonly ["keyed", "ref", "repeat", "live", "css", "html", "mathml", "staticHtml", "staticSvg", "svg", "safeClassMap", "safeStyleMap", "deferLoad", "stabilizedRef", "nothing"];
-export type JsxImportName = (typeof jsxImportNames)[number];
-export type JsxHost = ts.JsxElement | ts.JsxFragment | ts.JsxSelfClosingElement;
-/** Returns `true` if the given node is an array expression containing jsx nodes */
-export declare const isJsxArray: (node: ts.Node) => node is ts.ArrayLiteralExpression;
-export declare const isJsxHost: (node: ts.Node) => node is JsxHost;
-export {};

package/dist/jsxToLitHtml/utils.d.ts

@@ -1,14 +0,0 @@
-/**
- * Trim whitespace in the jsx text where safe, without breaking cases like this:
- * ```tsx
- * <p>Format: {text}</p>
- * ```
- *
- * This does not handle some cases if they are already handled by Prettier
- * (like trailing whitespace on a line, or two consecutive non-indent white-spaces)
- */
-export declare function safeTrimText(text: string): string;
-export declare const escapeForTemplateLiteral: (string: string) => string;
-export declare const shouldQuoteAttributeValue: (value: string) => boolean;
-export declare const escapeForHtml: (string: string) => string;
-export declare const isCustomElement: (tagName: string | symbol) => tagName is string;

package/dist/loader/css.d.ts

@@ -1,20 +0,0 @@
-import { CompilerContext } from '../context/index.ts';
-export declare function addGlobalCss(context: Pick<CompilerContext, "_globalHydratedCssString" | "apiJsonComponents" | "dir" | "isInStorybook" | "options" | "shouldMinify" | "viteCommand">): string;
-export declare const defaultHydratedAttribute = "hydrated";
-/**
- * Auto-inject the CSS when in dev server or when building for CDN to remove the
- * need for adding the `<link>` tag. Wrap styles in `@layer{}` to have lower
- * precedence than other styles in the head.
- *
- * @see https://discord.com/channels/1012791295170859069/1274527043614150708
- */
-export declare function getGlobalCssInjectionCode(globalCssString: string | undefined, context: Pick<CompilerContext, "_globalHydratedCssString" | "shouldMinify">): string;
-/**a
- * Get a CSS string that can be printed into a .css file
- *
- * Global CSS is auto-imported by bundlers. To ensure it is always loaded with
- * lower precedence order than user styles, we wrap it in `@layer{}`.
- *
- * @see https://devtopia.esri.com/WebGIS/arcgis-web-components/discussions/1824#discussioncomment-12625
- */
-export declare const getGlobalCssAsString: (context: CompilerContext) => string;

package/dist/loader/extractor.d.ts

@@ -1,2 +0,0 @@
-import { CompilerContext } from '../context/index.ts';
-export declare function configureApiExtractor(context: CompilerContext): Promise<void>;

package/dist/loader/index.d.ts

@@ -1,21 +0,0 @@
-import { Plugin as VitePlugin } from 'vite';
-import { CompilerContext } from '../context/index.ts';
-/**
- * Generate virtual files:
- * - loader.ts (for lazy loading components)
- *   - to generate this file, this plugin also generates api.json, and
- *     re-generates it in HMR
- * - setup files for tests
- *
- * The generated api.json is then used by componentTransformPipeline() and by
- * generateDocs(), among others.
- */
-export declare function generateVirtualFiles(context: CompilerContext): readonly [VitePlugin, VitePlugin, VitePlugin];
-/**
- * This function alone won't trigger a page refresh. However, if a page
- * is reloaded separately (by the browser or by lumina-compiler), the load()
- * plugin hook for loader.ts will be triggered, which would include updated
- * lazy meta
- */
-export declare function clearLoaderTsCache(context: CompilerContext): void;
-export declare const requestServerReload: (context: CompilerContext) => void;

package/dist/loader/lazy.d.ts

@@ -1,21 +0,0 @@
-import { CompilerContext } from '../context/index.ts';
-import { HmrComponentMeta } from '@arcgis/lumina/hmrSupport';
-import { ApiCustomElementDeclaration } from '@arcgis/api-extractor/apiJson';
-/**
- * To power bundle splitting for lazy loadable components, as well as to support
- * calling async methods before the component loaded, and to ensure frameworks
- * like React 19+ correctly pass properties to the lazy instance, we need to
- * generate a small metadata structure for each component. This will be
- * inserted into the root index.ts file in the package
- */
-export declare function buildLoaderTs(context: Pick<CompilerContext, "_globalHydratedCssString" | "apiJson" | "apiJsonComponents" | "dir" | "hmrEnabled" | "isInStorybook" | "options" | "privateApiJson" | "shouldMinify" | "viteCommand">): string;
-/**
- * For each component, build as compact definition as possible of all the public
- * properties, attributes, asynchronous methods and synchronous methods.
- */
-declare function buildCompactLazyMeta(customElement: Pick<ApiCustomElementDeclaration, "formAssociated" | "members" | "tagName">): string;
-export declare function buildLazyMeta(customElement: Pick<ApiCustomElementDeclaration, "formAssociated" | "members" | "tagName">): HmrComponentMeta;
-export declare const exportsForTests: {
-    buildCompactLazyMeta: typeof buildCompactLazyMeta;
-};
-export {};

package/dist/loader/storybookApiJson.d.ts

@@ -1,6 +0,0 @@
-import { ApiJson } from '@arcgis/api-extractor/apiJson';
-/**
- * Providing api.json to Storybook.
- * See https://github.com/storybookjs/storybook/tree/next/code/addons/docs/web-components
- */
-export declare function createStorybookApiJsonSetter(manifest: ApiJson): string;

package/dist/plugins/buildCdn.d.ts

@@ -1,73 +0,0 @@
-import { Plugin } from 'vite';
-import { CompilerContext } from '../context/index.ts';
-import { CdnChunk } from '../publicTypes.ts';
-/**
- * Restricted due to collisions with Lumina's dist/ folder names or
- * Stencil's dist/ folder names
- */
-export declare const restrictedNamespaceNames: Set<string>;
-export declare const defaultNamespace = "cdn";
-export declare const defaultEntryJsName = "index";
-export declare const globalCssName = "main";
-/**
- * CDN build works by reading the lazy NPM build and bundling-in all used
- * dependencies (except for imports of web components from dependencies - those
- * are assumed to be defined in the environment separately)
- */
-export declare function buildCdn(context: CompilerContext): Plugin | undefined;
-/**
- * Transform each core-importing chunk to use $arcgis.t for loading core in
- * order to be both ESM and AMD CDN compatible.
- *
- * Previous solution
- * (https://devtopia.esri.com/WebGIS/arcgis-web-components/pull/2995) relied on
- * top-level await. However, due to a Safari bug
- * (see https://devtopia.esri.com/WebGIS/arcgis-web-components/issues/3933
- * and https://bugs.webkit.org/show_bug.cgi?id=242740), we are no longer using
- * top-level await.
- *
- * Instead, we insert a top-level await polyfill - any module that imports core
- * directly or indirectly is transformed to have a promise as a default export -
- * such promise, once awaited, yields the actual exports of the module.
- *
- * List of other solutions considered:
- * https://devtopia.esri.com/WebGIS/arcgis-web-components/discussions/3999
- *
- * @example
- * ```js
- * /// BEFORE
- * import { b } from "./U7MU7PMX.js";
- * import { when as M } from "@arcgis/core/core/reactiveUtils.js";
- * var s = class extends v {
- *   // ...
- * };
- * export { s as ArcgisNavigationToggle };
- *
- * /// AFTER
- * import a from "./U7MU7PMX.js";
- * export default $arcgis.t(
- *   ([{ when: M }, { b }]) => {
- *     // The "meat" of the file is kept unchanged by the transform
- *     // (we only touch the imports, and the very last export line)
- *       s = class extends v {
- *         // ...
- *       };
- *     // Resolve the promise by returning the exported class
- *     return s;
- *   },
- *   "core/reactiveUtils",
- *   a,
- * );
- * ```
- */
-declare function transformChunk(chunk: CdnChunk, chunks: Map<string, CdnChunk>): void;
-/**
- * Given set of identifiers, produce the shortest possible ASCII-only identifier.
- * We restrict to ASCII-range as it is faster to parse for engines.
- */
-declare function createIdentifierGenerator(seen: Set<string>): () => string;
-export declare const exportsForTests: {
-    transformChunk: typeof transformChunk;
-    createIdentifierGenerator: typeof createIdentifierGenerator;
-};
-export {};

package/dist/plugins/buildWebApp.d.ts

@@ -1,3 +0,0 @@
-import { CompilerContext } from '../context/index.ts';
-/** @deprecated */
-export declare function buildWebApp(context: CompilerContext, rawDestination: string, cdnEntryName: string): Promise<void>;

package/dist/plugins/buildWrappers.d.ts

@@ -1,4 +0,0 @@
-import { Plugin } from 'vite';
-import { CompilerContext } from '../context/index.ts';
-/** @deprecated */
-export declare function buildWrappers(context: CompilerContext): Plugin;

package/dist/plugins/configureVite.d.ts

@@ -1,20 +0,0 @@
-import { Plugin } from 'vite';
-import { CompilerContext } from '../context/index.ts';
-import { InlineConfig } from 'vitest/node';
-import { PuppeteerTestingOptions } from '../publicTypes.ts';
-export type PuppeteerVitestConfigOptions = InlineConfig & {
-    puppeteerLaunchOptions?: PuppeteerTestingOptions["launchOptions"];
-    puppeteerWaitForChangesDelay?: number;
-};
-/**
- * Plugin to set up the common Vite configuration.
- *
- * @remarks
- * In order to respect the options user provided directly to Vite, we must
- * apply the user-provided options, and only fallback to our value if user did
- * not set a value.
- * Though, as per Vite's config merge logic, we only need to look up the default
- * value for literal value properties - objects and arrays are merged.
- * https://github.com/vitejs/vite/blob/bb4ba9f448da01782f585369f80c4517da087000/packages/vite/src/node/utils.ts#L1074
- */
-export declare const configureVite: (context: CompilerContext) => Plugin;

package/dist/plugins/externalizeDependencies.d.ts

@@ -1,30 +0,0 @@
-import { Plugin } from 'vite';
-import { CompilerContext } from '../context/index.ts';
-/**
- * By default, Rollup will bundle-in all dependencies.
- *
- * We change it as follows:
- * Externalize all packages that are defined as
- * "dependency" or "peerDependency" in the package.json.
- * If you wish to bundle-in some package, define it as a "devDependency".
- *
- * Bundling-in packages is not recommended because:
- * - it makes our build take longer
- * - it pushes larger packages to NPM
- * - user of our library is locked into the version of the package we bundled in
- * - if user has two packages using the same library, there will be two copies
- *   served on the page
- * - It may break some libraries/prevent them from optimizing correctly
- *   depending on the production/development mode, or prevent them from loading
- *   correct code depending on browser/node.js environment.
- *
- *   For example, see this statement from Lit:
- *   https://lit.dev/docs/ssr/authoring/#:~:text=Don%27t%20bundle%20Lit,based%20on%20environment.
- *
- * @see {@link ./buildCdn.ts} for CDN dependency bundling details
- *
- * @remarks
- * If a dependency is both a peerDependency and a devDependency, it will still
- * be externalized (because all peerDependencies are externalized).
- */
-export declare function externalizeDependencies(context: CompilerContext): Plugin;

package/dist/plugins/handleDynamicAssets.d.ts

@@ -1,8 +0,0 @@
-import { Plugin } from 'vite';
-import { CompilerContext } from '../context/index.ts';
-/**
- * Handle emit and serve for dynamically generated assets.
- * These assets are added by Lumina's plugins, as well as can be added by the
- * Lumina component package via the `assets.extra` option.
- */
-export declare const handleDynamicAssets: (context: CompilerContext) => Plugin;

package/dist/plugins/handleStaticAssets.d.ts

@@ -1,9 +0,0 @@
-import { Plugin } from 'vite';
-import { CompilerContext } from '../context/index.ts';
-/**
- * This is similar to Stencil's assets hosting, but to improve DX, the assets
- * belonging to each component are moved into a folder named after the component
- * to prevent collisions (or to remove need for manually creating redundant
- * sub-directories to avoid collisions).
- */
-export declare function handleStaticAssets(context: CompilerContext): Plugin;

package/dist/plugins/loadLitCss.d.ts

@@ -1,127 +0,0 @@
-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;

package/dist/plugins/printTotalBuildSize.d.ts

@@ -1,7 +0,0 @@
-import { Plugin } from 'vite';
-import { CompilerContext } from '../context/index.ts';
-/**
- * Augmenting vite's default reporter to not just report bundle sizes, but to
- * also print the total size
- */
-export declare const printTotalBuildSize: (context: CompilerContext) => Plugin;

package/dist/plugins/provideAssets.d.ts

@@ -1,35 +0,0 @@
-import { CompilerContext } from '../context/index.ts';
-import { AssetSpec, AssetTransformer } from '../publicTypes.ts';
-import { ContextDirectories } from '../context/types.ts';
-export declare function serveAssets(context: CompilerContext, assets: AssetSpec[], transformers?: AssetTransformer[]): void;
-export declare function writeAssets(context: CompilerContext, assets: AssetSpec[], transformers?: AssetTransformer[]): Promise<void>;
-/**
- * If trying to serve a file and destination does not include file name, take
- * file name from source
- */
-declare function addImplicitDistFileName(spec: AssetSpec): string;
-/**
- * Taking an absolute or relative destination path, resolve it as follows:
- * - Make absolute path be relative to the output base
- * - Prepend relative path with the serve base
- * - Ensure the resulting path does not escape above the output directory
- * - Ensure the path separators are correct for the current system
- */
-declare function resolveDistPath({ dist, distCdnAssets }: Pick<ContextDirectories, "dist" | "distCdnAssets">, rawDestination: string): string;
-/**
- * Take a resolved absolute file path in the dist directory, and from it infer
- * the path at which the file will be served.
- */
-declare function resolveServePath(baseUrl: string, resolvedDistPath: string, distCdnDir: string): string;
-/**
- * Given an array of absolute paths, make sure a parent directory for each file
- * exists
- */
-export declare function makeDirectoriesForFiles(files: readonly string[]): Promise<void>;
-export declare const defaultAssetTransformers: AssetTransformer[];
-export declare const exportsForTests: {
-    addImplicitDistFileName: typeof addImplicitDistFileName;
-    resolveDistPath: typeof resolveDistPath;
-    resolveServePath: typeof resolveServePath;
-};
-export {};

package/dist/plugins/setAssetsPath.d.ts

@@ -1,10 +0,0 @@
-import { Plugin } from 'vite';
-import { CompilerContext } from '../context/index.ts';
-/**
- * Plugin to set the base URL for assets in the package
- *
- * @remarks
- * In `@arcgis/storybook-utils` this plugin is removed so that the original
- * base URL is used (./)
- */
-export declare const setAssetPath: (context: CompilerContext) => Plugin;