@arcgis/lumina-compiler 4.31.0-next.100

package/dist/testing/mount.d.ts

@@ -0,0 +1,106 @@
+import type { TemplateResult } from "lit-html";
+import type { JsxNode, LitElement, ToElement } from "@arcgis/lumina";
+export type RenderResult<Component extends HTMLElement> = {
+    /**
+     * The custom element proxy that is attached to the DOM.
+     *
+     * This element will contain all the public properties and public methods of
+     * your custom element, but it will not contain any internal members.
+     */
+    readonly el: ToElement<Component> & {
+        shadowRoot: ShadowRoot;
+    };
+    /**
+     * This is the actual LitElement that you authored in the code.
+     *
+     * It is not directly connected to the DOM (instead, a proxy element is used
+     * to facilitate lazy-loading).
+     *
+     * All public and private members of your custom element are available here.
+     */
+    readonly component: Component;
+    /**
+     * A callback for triggering component re-render. Optionally, if the first
+     * argument to `mount()` was a function, that function will be called
+     * again to get a new template.
+     *
+     * @example
+     * ```tsx
+     * let someValue = 1;
+     * const { el, component, reRender } = await mount<ArcgisCounter>(
+     *   ()=><arcgis-counter someProp={someValue} />
+     * );
+     *
+     * someValue = 2;
+     * await reRender();
+     * ```
+     *
+     * The above is roughly equivalent to manually setting `el.someProp = 2`.
+     */
+    readonly reRender: () => Promise<boolean>;
+};
+export type RenderOptions<Component extends HTMLElement = HTMLElement> = {
+    /**
+     * The parent to attach this component to.
+     *
+     * @default document.body
+     */
+    readonly parent?: DocumentFragment | HTMLElement;
+    /**
+     * `mount()` will return a promise that resolves after the element
+     * is connected to the DOM, fully loaded and rendered.
+     *
+     * This callback is for executing code right after the element is connected to
+     * the DOM, but before it is fully loaded and rendered.
+     */
+    readonly afterConnect?: (el: ToElement<Component> & {
+        shadowRoot: ShadowRoot;
+    }) => Promise<void> | void;
+    /**
+     * This option only needs to be used if you created the custom element
+     * dynamically (inside the test file), rather than in a separate .tsx file.
+     * Also, if you already passed the dynamic custom element class as the first
+     * argument to `mount()`, you don't need to provide it again here.
+     */
+    readonly dynamicComponents?: (typeof LitElement)[];
+    /**
+     * Whether to cleanup the document body after the test. Set this to false if
+     * you wish to reuse the same component between different test() blocks.
+     *
+     * @default true
+     */
+    readonly cleanupAfterTest?: boolean;
+};
+/**
+ * Render Lit Element in a test environment.
+ *
+ * See documentation:
+ * https://qawebgis.esri.com/arcgis-components/?path=/docs/references-lumina-testing--docs
+ *
+ * @example
+ * ```tsx
+ * // Create component based on a tag name
+ * const { el, component } = await mount("arcgis-counter");
+ * // Create component based on JSX (explicit type annotation necessary)
+ * const { el, component } = await mount<"arcgis-counter">(<arcgis-counter />);
+ * // You can also use the component class as the explicit type annotation:
+ * const { el, component } = await mount<ArcgisCounter>(<arcgis-counter />);
+ * ```
+ *
+ * @remarks
+ * In it's simplest form, what this function is doing is the following:
+ *
+ * ```tsx
+ * import { render } from "lit-html";
+ * render(<arcgis-counter />, document.body);
+ * const el = document.querySelector("arcgis-counter")!;
+ * await el.componentOnReady();
+ * ```
+ */
+export declare function mount<const TagName extends keyof HTMLElementTagNameMap>(tagName: TagName, options?: RenderOptions<HTMLElementTagNameMap[TagName]>): Promise<RenderResult<HTMLElementTagNameMap[TagName]>>;
+export declare function mount<Class extends typeof LitElement>(template: TemplateResult | (() => JsxNode), options?: RenderOptions<InstanceType<Class>> & {
+    dynamicComponents: [Class];
+}): Promise<RenderResult<InstanceType<Class>>>;
+export declare function mount<TagName extends keyof HTMLElementTagNameMap = "wbr">(jsx: TemplateResult | (() => JsxNode), options?: RenderOptions<TagName extends "wbr" ? LitElement : HTMLElementTagNameMap[TagName]>): Promise<RenderResult<TagName extends "wbr" ? LitElement : HTMLElementTagNameMap[TagName]>>;
+export declare function mount<Class extends typeof LitElement>(template: Class | TemplateResult | (() => JsxNode), options?: RenderOptions<InstanceType<Class>>): Promise<RenderResult<InstanceType<Class>>>;
+export declare function mount<Component extends LitElement>(template: TemplateResult | (() => JsxNode) | (new () => Component), options?: RenderOptions<Component>): Promise<RenderResult<Component>>;

package/dist/testing/setupFile.d.ts

@@ -0,0 +1 @@
+export declare function setupLuminaTest(): void;

package/dist/testing/snapshotSerializer.d.ts

@@ -0,0 +1,12 @@
+/**
+ * Adds a vitest serializer for Shadow DOM.
+ * You do not need to call this function directly - `@arcgis/lumina-compiler` will
+ * configure Vitest to use this serializer automatically.
+ *
+ * @example
+ * ```tsx
+ * const { el, component } = await mount("arcgis-test1");
+ * expect(el.shadowRoot).toMatchInlineSnapshot(`<p>1</p>`);
+ * ```
+ */
+export declare function addShadowDomSerializer(): void;

package/dist/testing/wrapController.d.ts

@@ -0,0 +1,33 @@
+import type { BaseComponent, ControllerHost } from "@arcgis/components-controllers";
+import { LitElement } from "@arcgis/lumina";
+/**
+ * Wrap a controller in a small component - useful when you are interested in
+ * only testing the controller behavior.
+ *
+ * @example
+ * ```ts
+ * const testController = (): string => makeController(()=>'a');
+ * const { component } = await mount(wrapController(testController));
+ * expect(component.controller).toEqual("a");
+ * ```
+ *
+ * @example
+ * ```ts
+ * class TestController extends Controller {
+ *   a = "a";
+ * }
+ * const {
+ *   component: { controller }
+ * } = await mount(wrapController(TestController));
+ * expect(controller.a).toEqual("a");
+ * ```
+ */
+export declare function wrapController<T>(controller: ((component: BaseComponent & ControllerHost) => T) | (new (component: BaseComponent & ControllerHost) => T), 
+/**
+ * An optional callback to call right after controller constructor
+ */
+afterConstruct?: (component: LitElement & {
+    controller: T;
+}) => Promise<void> | void): typeof LitElement & (new () => LitElement & {
+    controller: T;
+});

package/dist/tests/utils.d.ts

@@ -0,0 +1,4 @@
+import type { ContextDirectories } from "../context/types";
+import type { CompilerContext } from "../context";
+export declare const testDir: ContextDirectories;
+export declare const testContext: Pick<CompilerContext, "dir" | "documentationFileNames">;

package/dist/transformers/guardAgainstInternalJsDoc.d.ts

@@ -0,0 +1,11 @@
+import type { FileTransformer } from "../publicTypes";
+/**
+ * Custom-elements-manifest excludes `@internal` things from the
+ * manifest, without letting us do much about it. We still want these
+ * to appear in the manifest so that they are included in the lazy
+ * component meta - without that, lazy-loading won't work correctly
+ *
+ * Opened an issue:
+ * https://github.com/open-wc/custom-elements-manifest/issues/263
+ */
+export declare const guardAgainstInternalJsDoc: FileTransformer;

package/dist/transformers/index.d.ts

@@ -0,0 +1,22 @@
+import type { Plugin } from "vite";
+import type { CompilerContext } from "../context";
+import ts from "typescript";
+/**
+ * A pipeline of transformers for .tsx files.
+ * Only .tsx files are touched as all transformations deal with components and
+ * components should be defined in .tsx files.
+ *
+ * Instead of having separate transform() vite plugins, and each plugin having
+ * to generate a source map (or forgetting to do so and breaking DX) and then
+ * having Vite merge those source maps (Vite's source map merging can loose
+ * precision), the pipeline is just a list of TypeScript transformers
+ * efficiently applied one after another.
+ *
+ * And at the end, TypeScript will generate the source map for us - it does it
+ * in a smart way - if we re-use the original typescript node during
+ * transformation, then that node has original position information attached to
+ * it - thus, even if transformer moves things around a lot, TypeScript can
+ * still create a great source map.
+ */
+export declare const componentTransformPipeline: (context: CompilerContext) => Plugin;
+export declare function getCompilerOptionsForPrinter(context: CompilerContext): ts.CompilerOptions;

package/dist/transformers/injectRuntimeOptions.d.ts

@@ -0,0 +1,3 @@
+import type { SourceDescription } from "rollup";
+import type { CompilerContext } from "../context";
+export declare function injectRuntimeOptions(runtimeTsCode: string, context: CompilerContext): SourceDescription;

package/dist/transformers/internalTypeScriptApis.d.ts

@@ -0,0 +1,29 @@
+import type { SourceMap } from "rollup";
+import ts from "typescript";
+export type UndocumentedTypeScript = {
+    readonly createSourceMapGenerator?: (host: ts.CompilerHost, basename: string, sourceRoot: string, dirname: string, compilerOptions: ts.CompilerOptions) => SourceMapGenerator;
+    readonly createTextWriter?: (newLine: string) => EmitTextWriter;
+    readonly getNewLineCharacter?: (options: ts.CompilerOptions) => string;
+    readonly createPrinter: (
+    /**
+     * Printer has undocumented options for printing source maps:
+     * https://github.com/microsoft/TypeScript/blob/7319968e90600102892a79142fb804bcbe384160/src/compiler/types.ts#L9689C18-L9707
+     */
+    options: ts.CompilerOptions & ts.PrinterOptions) => ReturnType<typeof ts.createPrinter> & UndocumentedPrinter;
+};
+type SourceMapGenerator = {
+    readonly toJSON: () => SourceMap;
+};
+type UndocumentedPrinter = {
+    readonly writeFile?: (writeFile: ts.SourceFile, writer: EmitTextWriter, sourceMapGenerator: SourceMapGenerator | undefined) => void;
+    writeNode?(hint: ts.EmitHint, node: ts.TypeNode, sourceFile: undefined, output: EmitTextWriter): void;
+    writeNode?(hint: ts.EmitHint, node: Node, sourceFile: ts.SourceFile, output: EmitTextWriter): void;
+};
+type EmitTextWriter = {
+    readonly getText: () => string;
+    readonly clear: () => void;
+};
+export declare const undocumentedTs: Required<UndocumentedTypeScript>;
+export declare function getPrinter(compilerOptions: ts.CompilerOptions): ReturnType<typeof createPrinter>;
+declare function createPrinter(compilerOptions: ts.CompilerOptions): ReturnType<typeof ts.createPrinter> & UndocumentedPrinter;
+export {};

package/dist/transformers/liftDecorators.d.ts

@@ -0,0 +1,21 @@
+import ts from "typescript";
+export type LiftedDecorators = Map<string, ts.ObjectLiteralExpression>;
+/**
+ * Using decorators in a file means shipping TypeScript's decorator polyfill.
+ * Plus, the decorator polyfill is meant to be generic and so adds more code
+ * than needed.
+ *
+ * Fortunately, Lit supports a static "properties" property (mainly for
+ * non-TypeScript users) that can be used to define properties in a more
+ * build size efficient way, without the need for `@property()` or `@state()`
+ * decorators.
+ *
+ * @remarks
+ * Without this, map-components CDN build is 398kb.
+ * With lifted decorator, it is 364kb (34kb smaller).
+ * AND, with compact property options it's 354kb (7kb smaller).
+ *
+ * For comparison, map-components Stencil CDN build is 370kb (and they
+ * lift all decorators too).
+ */
+export declare function liftDecorators(members: readonly ts.ClassElement[], liftedDecorators: LiftedDecorators, minifyFlags: boolean): readonly ts.ClassElement[];

package/dist/transformers/members.d.ts

@@ -0,0 +1,12 @@
+import ts from "typescript";
+import type { FileTransformContext, FileTransformer } from "../publicTypes";
+/**
+ * - Remove `@Method()` decorators from the code. `@Method()` decorators are
+ *   only needed for the docs extraction.
+ * - Add `{ type: Number }` or `{ type: Boolean }` to `@property()` where
+ *   necessary
+ * - Replace `@property()` decorators with `static properties = {}` to reduce
+ *   bundle size.
+ */
+export declare const transformMembers: FileTransformer;
+export declare function visitComponentMembers<T extends ts.Node>(memberVisitor: (member: ts.ClassElement, className: string | undefined) => ts.ClassElement, node: T, context: FileTransformContext, beforeMembers?: () => void, afterMembers?: (node: ts.ClassElement[]) => readonly ts.ClassElement[]): T;

package/dist/transformers/property.d.ts

@@ -0,0 +1,9 @@
+import ts from "typescript";
+import type { FileTransformContext } from "../publicTypes";
+import type { LiftedDecorators } from "./liftDecorators";
+export declare function transformProperty(context: FileTransformContext, property: ts.AccessorDeclaration | ts.PropertyDeclaration, className: string | undefined, sourceFile: ts.SourceFile, makeOriginalSourceFileEdit: (from: number, to: number, replaceWith: string) => void, liftedDecorators?: LiftedDecorators): ts.ClassElement;
+export type ParsedPropertyDecorator = {
+    decorator: ts.Decorator;
+    callExpression: ts.CallExpression;
+    options: ts.ObjectLiteralExpression | undefined;
+};

package/dist/transformers/propertyOptions.d.ts

@@ -0,0 +1,111 @@
+import ts from "typescript";
+import type { FileTransformContext } from "../publicTypes";
+import type { ExtendedManifestField } from "../manifests/complexTypes/types";
+import type { ParsedPropertyDecorator } from "./property";
+/**
+ * In Stencil, the compiler uses type checking to determine if the inferred
+ * property type is number or boolean, and if so, would make sure to cast the
+ * string attribute value to number or boolean. Even in development mode type
+ * checking is used for that - which is not ideal as it slows down the dev server.
+ *
+ * That is why in Lumina we are no doing type checking at all (not even
+ * creating a TypeScript program) in the dev server. That of course puts some
+ * constraints on us.
+ *
+ * In Lit, since there is no compiler, Lit relies on the `{type: Number}` or
+ * `{type: Boolean}` property being passed to the `@property` decorator to
+ * determine if the property should be cast.
+ *
+ * Looking at all usages of number and boolean properties in Calcite and
+ * map-components, I see a few patterns:
+ *
+ * - In Calcite:
+ *
+ *   - all boolean properties either explicitly have "false" as a default value,
+ *     or explicitly have `boolean` type in TypeScript - in this case the AST
+ *     contains enough information for lumina-compiler to insert `{type: Boolean}`
+ *     in the code at build-time.
+ *   - most number properties either have `number` type in TypeScript or numeric
+ *     default value. This however is not always the case as there are a few
+ *     exceptions:
+ *
+ *     - calcite-action-group.columns: uses `Columns` number enum as it's type
+ *     - calcite-block.headingLevel: uses `HeadingLevel` number enum as it's
+ *       type
+ *     - calcite-pagination.maxItems, calcite-popover.offsetDistance and
+ *       calcite-tooltip.offsetDistance: use a const variable of numeric type as
+ *       their default value
+ *
+ *     These cases can't be inferred from the AST alone
+ *
+ * - In Map Components:
+ *
+ *   - here the story is complicated by the fact that we use the following
+ *     Controllers syntax in a lot of places:
+ *
+ *     ```tsx
+ *     \@Prop() hideCreateFeaturesSection = this.widget.visibleElements.createFeaturesSection;
+ *     ```
+ *
+ *     In the above, the type is boolean, but we can't know that from the AST.
+ *
+ * Since we can use the type checker during build, I am considering solving the
+ * issue like this:
+ *
+ * - both in serve and build mode, look at the AST to see if we can trivially
+ *   infer whether the property type is number or boolean
+ * - in build mode:
+ *   - if has a custom converter specified, don't do anything
+ *   - else, if trivially inferred that property is boolean and number:
+ *     - if has explicit type annotation:
+ *       - if type annotation is of type number or boolean:
+ *         - edit the source code to automatically remove the useless type
+ *           annotation, and add a small log message to notify dev about what
+ *           happened
+ *       - warn about mismatching type annotation
+ *     - add {type:Number} or {type:Boolean} to the .js output code, not source
+ *       code
+ *   - else, use the type checker, with an algorithm similar to Stencil to
+ *     detect if property type is number or boolean
+ *     - if detected that property type is not number or boolean
+ *       - don't do anything
+ *     - else, if property type is number or boolean
+ *       - edit the source file to automatically add the type annotation
+ *         and add a small log message to notify dev about what happened
+ *       - add `{type:Number}` or `{type:Boolean}` to the .js output code
+ *     - else, don't do anything
+ * - in dev mode:
+ *   - if type or converter is explicitly present
+ *     - don't do anything
+ *   - if inferred that property type is number or boolean
+ *     - add `{type:Number}` or `{type:Boolean}` to the .js output code, not
+ *       source code
+ *
+ * The benefits of the above:
+ *
+ * - dev build is fast as no type checking is happening
+ * - source code is clean as type annotations are not present, unless ambiguous
+ * - in ambiguous cases, the source code has an explicit annotation, which
+ *   ensures the serve mode has the same behavior as build for all properties
+ *   - ambiguous newly added properties in serve mode won't yet have an explicit
+ *     type annotation, but that is okay as ambiguous number/boolean properties
+ *     are not that common, and in development mode properties are often set as
+ *     JavaScript properties rather than HTML attributes, thus bypassing the
+ *     need to cast the property
+ * - when converting a codebase from Stencil to Lit (either manually or using
+ *   the codemod), the type annotations in ambiguous places would be inserted
+ *   automatically if not yet present
+ * - when converting wrapped map-components widget to native, most usages of a
+ *   code style like this will be removed, to be replaced with unambiguous
+ *   `false` default value:
+ *
+ *   ```tsx
+ *   \@Prop() hideCreateFeaturesSection = this.widget.visibleElements.createFeaturesSection;
+ *   ```
+ *
+ *   In such cases, the above algorithm will automatically remove the now
+ *   useless type annotation.
+ *
+ * See also https://github.com/runem/lit-analyzer/blob/master/packages/lit-analyzer/src/lib/rules/no-incompatible-property-type.ts
+ */
+export declare function transformPropertyOptions(property: ts.AccessorDeclaration | ts.PropertyDeclaration, decorator: ParsedPropertyDecorator, context: FileTransformContext, sourceFile: ts.SourceFile, makeOriginalSourceFileEdit: (from: number, to: number, replaceWith: string) => void, propertyManifest: ExtendedManifestField | undefined): ts.ObjectLiteralExpression | undefined;

package/dist/transformers/updateOriginalFile.d.ts

@@ -0,0 +1,20 @@
+import type { FileTransformContext } from "../publicTypes";
+/**
+ * Update the original source file to add `{ type : Number }` or
+ * `{ type : Boolean }`.
+ *
+ * We can't simply reuse the result from the transformer because other
+ * transformers may have modified this file beforehand. Instead, we create a new
+ * ts.SourceFile from the file system source file, and re-run just this single
+ * transformer on it.
+ *
+ * @remarks
+ * Using synchronous fs in this file because:
+ * - most of the time this function will not be called, so the performance
+ *   impact is negligible
+ * - the transformer pipeline is sync, so having async functions in it is only
+ *   possible if we don't await the result
+ * - async fs may interfere with another plugin reading/writing the source code
+ *   file at the same time
+ */
+export declare function updateSourceFilePropertyTypes(context: FileTransformContext, filePath: string): void;

package/dist/transformers/utils.d.ts

@@ -0,0 +1,14 @@
+import ts from "typescript";
+import type { FileTransformer } from "../publicTypes";
+import type { CompilerContext } from "../context";
+/**
+ * Run a chain of transformers on a TypeScript .tsx or .d.ts file and return
+ * the resulting source file
+ */
+export declare function runTransformers(context: CompilerContext, transformationContext: ts.TransformationContext, sourceFile: ts.SourceFile, transformers: readonly FileTransformer[]): ts.SourceFile;
+/**
+ * For performance reasons, to avoid the need to re-create the source map
+ * after this change, replace the given code string with a comment string of
+ * equal length :)
+ */
+export declare const commentOutCode: (match: string) => string;

package/dist/types/astTransformers.d.ts

@@ -0,0 +1,3 @@
+import type { CompilerContext } from "../context";
+import type { PluginOptions } from "vite-plugin-dts";
+export declare function runAstDtsTransformers(context: CompilerContext): NonNullable<PluginOptions["resolvers"]>[number];

package/dist/types/hideInternalLitElement.d.ts

@@ -0,0 +1,9 @@
+import type { FileTransformer } from "../publicTypes";
+/**
+ * Modify the .d.ts to make it appear that components extend the
+ * PublicLitElement rather than LitElement
+ *
+ * This will hide internal methods like addController() and connectedCallback()
+ * from the public typings
+ */
+export declare const hideInternalLitElement: FileTransformer;

package/dist/types/index.d.ts

@@ -0,0 +1,18 @@
+import type { Plugin } from "vite";
+import type { CompilerContext } from "../context";
+/**
+ * Generate TypeScript definition files for the files in the project.
+ * There is a corresponding .d.ts file emitted for each source .ts and .tsx file.
+ *
+ * Separately, in ./frameworkTypes typings we produce typings for framework and
+ * vanilla JavaScript users
+ *
+ * @remarks
+ * Because vite-plugin-dts creates ts.SourceFile instances during
+ * buildStart(), any changes to files in any of our transform() hooks won't be
+ * reflected in the final .d.ts files (unless we create new ts.SourceFile
+ * objects but that may be computationally expensive).
+ * Thus for now we are using beforeWriteFile() hook that vite-plugin-dts
+ * provides to modify the files before they are output.
+ */
+export declare function generateTypes(context: CompilerContext): Plugin;

package/dist/types/liftSetterTypes.d.ts

@@ -0,0 +1,33 @@
+import type { PropertyDeclaration } from "typescript";
+import ts from "typescript";
+import type { CompilerContext } from "../context";
+export type LiftedSetter = {
+    name: ts.PropertyName;
+    type: ts.TypeNode;
+    isRequired: boolean;
+};
+export declare const setterTypesPropertyName = "_setterTypes";
+/**
+ * In TypeScript, if getter and setter have different types, there is no way
+ * to get the setter type - you can only get the getter type.
+ *
+ * For JSX typings, we need the setter types. As a workaround, we create a
+ * types-only property on the component class that contains the types for the
+ * setter properties. Then, the JSX typings retrieve the type from this
+ * property.
+ *
+ * @see https://github.com/microsoft/TypeScript/issues/43729
+ */
+export declare function addLiftedSettersProperty(setters: LiftedSetter[], sourceFile: ts.SourceFile, context: CompilerContext): PropertyDeclaration;
+/**
+ * Despite the fact that TypeScript AST nodes are immutable, we can not have the
+ * same node in two places in the AST. Cloning nodes is also quite tricky.
+ *
+ * There is a gigantic library for this (that is also unmaintained and does not
+ * support TypeScript 5): https://github.com/wessberg/ts-clone-node
+ *
+ * The other option is to print the node and parse it again, which is what we
+ * are doing here. TypeScript does not expose the APIs to parse individual
+ * nodes, so we must parse the entire source file.
+ */
+export declare function clonePropertyParts(name: ts.PropertyName, type: ts.TypeNode, printer: ts.Printer, sourceFile: ts.SourceFile): readonly [name: ts.PropertyName, type: ts.TypeNode];

package/dist/types/textTransformers.d.ts

@@ -0,0 +1,4 @@
+import type { CompilerContext } from "../context";
+import type { PluginOptions } from "vite-plugin-dts";
+export declare const runTextDtsTransformers: (context: CompilerContext) => PluginOptions["beforeWriteFile"];
+export declare const isTestFile: (id: string) => boolean;

package/dist/types/transformComponentMembers.d.ts

@@ -0,0 +1,10 @@
+import type { FileTransformer } from "../publicTypes";
+/**
+ * Cleanup public component typings:
+ * - Hide all non-property, non-events, non-methods from public typings
+ * - Add `readonly` modifier for readonly properties
+ * - Remove internal emit() method from event typings
+ * - Make all event properties readonly
+ * - Remove all static members
+ */
+export declare const transformComponentMembers: FileTransformer;

package/dist/useLumina.d.ts

@@ -0,0 +1,13 @@
+import type { LuminaPlugins, LuminaOptions } from "./publicTypes";
+/**
+ * Auto-configure Vite for a Lit web component project.
+ *
+ * Main features:
+ * - Main entrypoint lazy-loads all components on demand
+ * - Allow you to author your components in JSX for great developer experience,
+ *   and convert JSX to lit-html templates at build time for maximum efficiency
+ * - Separate bundle for each component to bundle only the necessary code
+ * - Generates types, docs, and manifests for web components
+ * - Generates a CDN build
+ */
+export declare function useLumina(options?: LuminaOptions): LuminaPlugins;

package/dist/utils/error.d.ts

@@ -0,0 +1,4 @@
+/**
+ * Throw if trying to access a property that was not provided, or set any property
+ */
+export declare const throwOnUnknown: (base: Record<string, unknown>) => unknown;

package/dist/utils/packageJson.d.ts

@@ -0,0 +1,24 @@
+/**
+ * A subset of the package.json typing that is interesting to Lumina.
+ *
+ * The full package.json type is insanely large (20k lines):
+ * https://github.com/ffflorian/schemastore-updater/blob/main/schemas/package/index.d.ts#L20067
+ */
+export type MiniPackageJson = {
+    "name": string;
+    "version": string;
+    "dependencies"?: Record<string, string>;
+    "devDependencies"?: Record<string, string>;
+    "peerDependencies"?: Record<string, string>;
+    "css.customData"?: string[];
+    "customElements"?: string;
+    "html.customData"?: string[];
+    "web-types"?: string;
+};
+export declare function retrievePackageJson(location?: string): MiniPackageJson;
+export declare function asyncRetrievePackageJson(location?: string): Promise<MiniPackageJson>;
+/**
+ * Returns an absolute path to the root of a package in node_modules, without
+ * trailing slash.
+ */
+export declare function fetchPackageLocation(packageName: string, cwd?: string): Promise<string>;

package/dist/utils/path.d.ts

@@ -0,0 +1,25 @@
+/**
+ * See ../path.md for details about our path handling.
+ */
+/// <reference types="node" />
+import posix from "path/posix";
+/**
+ * This is called "isPosix" rather than "isNotWindows" because even if we are
+ * on Windows, we could be running in a POSIX environment (e.g. WSL2)
+ */
+export declare const isPosix: boolean;
+export declare const toPosixPathSeparators: (relativePath: string) => string;
+/**
+ * On Windows, replace all `/` in the path back with `\\`. Do this only if you
+ * wish to output the path in the console or error message.
+ * On POSIX system (macOS, Linux, ...), this does not change the path (because
+ * inside the compiler we use `/` everywhere).
+ */
+export declare const toSystemPathSeparators: (relativePath: string) => string;
+export declare const getCwd: () => string;
+export declare const path: typeof posix & {
+    sep: "/";
+};
+export declare const exportsForTests: {
+    toWin32PathSeparators: (relativePath: string) => string;
+};

package/dist/utils/path.spec.d.ts

@@ -0,0 +1 @@
+export {};