@arcgis/lumina-compiler 4.31.0-next.100

package/dist/manifests/complexTypes/transformUtils.d.ts

@@ -0,0 +1,130 @@
+import ts from "typescript";
+import type { Reference } from "custom-elements-manifest/schema";
+import { type FullerJsonDocValue } from "./typeToEnum";
+import type { ContextDirectories } from "../../context/types";
+export declare const addPropMetadataPluginName = "@arcgis/lumina:addPropMetadata";
+/**
+ * Resolve a type annotation, using the TypeScript typechecker to convert a
+ * {@link ts.Type} record to a string.
+ *
+ * For instance, assume there's a module `foo.ts` which exports a type `Foo`
+ * which looks like this:
+ *
+ * ```ts
+ * // foo.ts
+ * type Foo = (b: string) => boolean;
+ * ```
+ *
+ * and then a module `bar.ts` which imports `Foo` and uses it to annotate a
+ * variable declaration like so:
+ *
+ * ```ts
+ * // bar.ts
+ * import { Foo } from './foo';
+ *
+ * let foo: Foo | undefined;
+ * ```
+ *
+ * If this function is called with the {@link ts.Type} object corresponding to
+ * the {@link ts.Node} object for the `foo` variable, it will return something
+ * like:
+ *
+ * ```ts
+ * "(b: string) => boolean | undefined";
+ * ```
+ *
+ * @param checker a typescript typechecker
+ * @param type the type to resolve
+ * @returns a resolved, user-readable string
+ *
+ * @remarks
+ * Based on Stencil's resolveType function:
+ * https://github.com/ionic-team/stencil/blob/b40ebb937869aa16f9adc672129639167406cd07/src/compiler/transformers/transform-utils.ts#L616
+ */
+export declare function typeNodeToTypeValues(typeNode: ts.TypeNode): FullerJsonDocValue[];
+export declare const typeValuesToString: (typeValues: FullerJsonDocValue[]) => string;
+/**
+ * Formats a TypeScript `TypeNode` entity as a string
+ *
+ * @remarks
+ * Based on TypeScripts's typeToString function
+ * (defined in https://github.com/microsoft/TypeScript/blob/main/src/compiler/checker.ts)
+ *
+ * Using this function is almost equivalent to calling TypeScript's
+ * `checker.typeToString(type, undefined, typeFormatFlags);`, but our version
+ * correctly prints multiline object literals rather than glueing it into one
+ * unreadable line (thanks to textWriter using "\n" line separator, vs "" in the
+ * TypeScript's implementation).
+ *
+ * Also, TypeScript's typeToString converts the Type it receives to TypeNode.
+ * Since we need a TypeNode reference anyway for other purposes, that is a bit
+ * redundant - thus our version accepts at TypeNode directly
+ */
+export declare function typeNodeToString(typeNode: ts.TypeNode): string;
+/**
+ * For documentation purposes, we care about resolved type rather than the
+ * unresolved type.
+ * The unresolved type can leak implementation details or be less helpful to the
+ * user.
+ *
+ * @example
+ * In case like:
+ * ```tsx
+ * const someInternalStyleVariable: CSSResult!;
+ * \@property() style?: typeof someInternalStyleVariable;
+ * ```
+ *
+ * The resolved type is `CSSResult | undefined`, which is more helpful
+ * than the unresolved type `typeof someInternalStyleVariable | undefined`
+ */
+export declare function typeToResolvedTypeNode(checker: ts.TypeChecker, type: ts.Type, 
+/** Optional callback to call for each traversed type */
+callback?: (type: Partial<ts.Type>, isElReference: boolean) => void): ts.TypeNode;
+export declare function typeToResolvedTypeNodeWithReferences(checker: ts.TypeChecker, type: ts.Type, sourceFile: ts.SourceFile, dirs: ContextDirectories): {
+    typeNode: ts.TypeNode;
+    references: Reference[];
+};
+/**
+ * This is not made up by us - defined in the custom-elements-manifest spec
+ */
+export declare const globalPackageIdentifier = "global:";
+/**
+ * Given an absolute path to a module, parse the package name and module name
+ * in case of external module reference, or return relative path in case of
+ * internal references
+ */
+declare function parseModulePath(absoluteModulePath: string, dirs: ContextDirectories): ModulePath;
+/**
+ * @example
+ * ```ts
+ * parsePackageSpecifier("@esri/calcite-components/dist/components");
+ * // { packageName: "@esri/calcite-components", moduleName: "dist/components" }
+ * ```
+ */
+export declare function parsePackageSpecifier(packageSpecifier: string): ModulePath;
+export declare const isExternalFile: (modulePath: string) => boolean;
+export type ModulePath = {
+    readonly packageName: string | undefined;
+    readonly moduleName: string;
+};
+/**
+ * Helper method for retrieving modifiers from a TypeScript {@link ts.Node} entity.
+ *
+ * Starting with TypeScript v4.8, decorators and modifiers have been coalesced into a single field, and retrieving
+ * modifiers directly has been deprecated. This helper function is a utility that wraps various helper functions that
+ * the TypeScript compiler exposes for pulling modifiers out of said field.
+ *
+ * @see {@link https://devblogs.microsoft.com/typescript/announcing-typescript-4-8/#decorators-are-placed-on-modifiers-on-typescripts-syntax-trees|The TypeScript 4.8 Announcement}
+ *
+ * @param node the node to pull modifiers out of
+ * @returns a list containing 1+ modifiers on the node, otherwise undefined
+ *
+ * @remarks
+ * Based on Stencil's retrieveTsModifiers function:
+ * https://github.com/ionic-team/stencil/blob/b40ebb937869aa16f9adc672129639167406cd07/src/compiler/transformers/transform-utils.ts#L945
+ */
+export declare const retrieveTsModifiers: (node: ts.Node) => readonly ts.Modifier[] | undefined;
+export declare const exportsForTests: {
+    parseModulePath: typeof parseModulePath;
+};
+export {};

package/dist/manifests/complexTypes/transformUtils.spec.d.ts

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

package/dist/manifests/complexTypes/typeToEnum.d.ts

@@ -0,0 +1,14 @@
+import type { JsonDocsValue } from "@stencil/core/internal";
+export type FullerJsonDocValue = JsonDocsValue & {
+    raw: string;
+};
+/**
+ * @remarks
+ * Based on Stencil's parseTypeIntoValues function:
+ * https://github.com/ionic-team/stencil/blob/446d194118756d38d024138eb9e83efe7d9e679e/src/compiler/docs/generate-doc-data.ts#L233
+ *
+ * But, instead of re-parsing the resolved type string, we are formatting each
+ * type union part right away. That is because Stencil's version incorrectly
+ * re-parses type strings like `{ value: string | undefined }`.
+ */
+export declare function formatTypeString(raw: string): FullerJsonDocValue;

package/dist/manifests/complexTypes/typeToEnum.spec.d.ts

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

package/dist/manifests/complexTypes/types.d.ts

@@ -0,0 +1,135 @@
+import type { CustomElementField, Package, Reference } from "custom-elements-manifest/schema";
+import type { Type, ClassMethod, CustomElement, Event } from "custom-elements-manifest/schema";
+/**
+ * Information about a type used in a project
+ *
+ * @remarks
+ * Based on Stencil's ComponentCompilerTypeReferences type:
+ * https://github.com/ionic-team/stencil/blob/b40ebb937869aa16f9adc672129639167406cd07/src/declarations/stencil-private.ts#L700
+ */
+export type ComponentCompilerPropertyComplexType = {
+    /**
+     * The string of the original type annotation in the Lit source code
+     */
+    readonly original: Type["text"];
+    /**
+     * A 'resolved' type, where e.g. imported types have been resolved and inlined
+     *
+     * For instance, an annotation like `(foo: Foo) => string;` will be
+     * converted to `(foo: { foo: string }) => string;`.
+     */
+    readonly resolved: string;
+    /**
+     * A record of the types which were referenced in the assorted type
+     * annotation in the original source file.
+     */
+    readonly references: Exclude<Type["references"], undefined>;
+    /**
+     * Whether `@property` decorator has readonly:true
+     */
+    readonly isReadonly: boolean;
+    values: {
+        value?: string;
+        type: string;
+    }[] | undefined;
+    readonly isAttributeEligible: boolean;
+};
+export type ComponentCompilerEventType = ComponentCompilerPropertyComplexType & Pick<ExtendedManifestEvent, "bubbles" | "cancelable" | "composed"> & {
+    readonly eventName: string;
+};
+export type ExtendedComponentManifest = Package & {
+    /**
+     * The timestamp at which the metadata was generated, in the format YYYY-MM-DDThh:mm:ss
+     */
+    timestamp: string;
+    compiler: {
+        /**
+         * The name of the compiler that generated the metadata
+         */
+        name: string;
+        /**
+         * The version of the compiler that generated the metadata
+         */
+        version: string;
+        /**
+         * The version of TypeScript that was used to generate the metadata
+         */
+        typescriptVersion: string;
+    };
+};
+export type ExtendedManifestCustomElement = CustomElement & {
+    /**
+     * This is added by custom-elements-manifest, not us, but they forgot to add
+     * it to their typings...
+     */
+    kind: "class";
+    docsTags?: JsonDocsTag[];
+    /** @example "src/components/area-measurement-2d/area-measurement-2d.tsx" */
+    sourcePath: string;
+    /**
+     * The path from which the component can be imported.
+     *
+     * @example "components/arcgis-area-measurement-2d"
+     */
+    importPath: string;
+    encapsulation: "none" | "shadow";
+    /** @example "HTMLArcgisCounterElement" */
+    typeName: string;
+};
+export type ExtendedManifestField = CustomElementField & {
+    hasQuestionToken?: boolean;
+    docsTags?: JsonDocsTag[];
+    type?: ExtendedManifestType;
+    /**
+     * If field has both getter and setter, and their types are different, this
+     * will contain the getter type.
+     */
+    getterType?: ExtendedManifestType;
+    /**
+     * This is added by custom-elements-manifest, not us, but they forgot to add
+     * it to their typings...
+     */
+    readonly?: boolean;
+    /**
+     * For some properties, we show them as read-only in the docs and in the
+     * typings but don't actually enforce read-only at runtime.
+     *
+     * Such properties are represented in the manifest with both `readonly` and
+     * `docsOnlyReadonly` set to true.
+     *
+     * Runtime read-only properties are represented with only `readonly` true.
+     */
+    docsOnlyReadonly?: boolean;
+};
+export type ExtendedManifestMethod = ClassMethod & {
+    docsTags?: JsonDocsTag[];
+    type: {
+        signature: string;
+        references: Reference[];
+    };
+    async?: boolean;
+};
+export type ExtendedManifestEvent = Event & {
+    type?: ExtendedManifestType;
+    docsTags?: JsonDocsTag[];
+    bubbles: boolean;
+    cancelable: boolean;
+    composed: boolean;
+};
+export type InternalManifestField = {
+    isAttributeEligible?: boolean;
+};
+export type ExtendedManifestType = Pick<ComponentCompilerPropertyComplexType, "original" | "values"> & Type;
+/**
+ * A descriptor for a single JSDoc tag found in a block comment
+ */
+export type JsonDocsTag = {
+    /**
+     * The tag name (immediately following the '@')
+     */
+    name: string;
+    /**
+     * The description that immediately follows the tag name
+     */
+    text?: string;
+};

package/dist/manifests/config.d.ts

@@ -0,0 +1,2 @@
+import type { ManifestType } from "./types";
+export declare const defaultManifestFileNames: Record<ManifestType, string>;

package/dist/manifests/createManifest.d.ts

@@ -0,0 +1,39 @@
+/// <reference path="../../src/manifests/createManifestTyping.d.ts" />
+import { create } from "@custom-elements-manifest/analyzer/src/browser-entrypoint.js";
+import ts from "typescript";
+import type { PropMetadataContext } from "./complexTypes/addPropMetadata";
+import { type ComponentManifest } from "./utils";
+import type { ExtendedComponentManifest } from "./complexTypes/types";
+import type { CompilerContext } from "../context";
+/**
+ * Based on https://github.com/Kamiapp-fr/vite-plugin-cem/blob/main/src/create.ts
+ *
+ * PERF: this includes a lot of default plugins we don't need (for extracting
+ * variables, functions and mixins). We can't exclude them by default without
+ * implementing our own create() (which is quite doable as it's only 100 lines
+ * of code) or using patch-package. Opened a feature request:
+ * https://github.com/open-wc/custom-elements-manifest/issues/262
+ */
+export declare function createManifest(props: Parameters<typeof create>[0], context: CompilerContext, 
+/** Whether we are simply patching existing manifest */
+isHmr: boolean): ExtendedComponentManifest;
+/**
+ * These members are always present on the proxy element, thus should not be
+ * added in the lazy meta like all others. They are also not applicable for JSX
+ * typings.
+ */
+export declare const speciallyInheritedMembers: Set<string>;
+export type CustomElementManifestPluginContext = {
+    sourceFile?: ts.SourceFile;
+    lastAccessors?: Record<string, ts.AccessorDeclaration>;
+    lonelyGetters?: Set<string>;
+    state?: ManifestState;
+    states: ManifestState[];
+    thirdPartyCEMs?: ExtendedComponentManifest[];
+};
+type ManifestState = {
+    readonly component: ComponentManifest;
+    readonly events: PropMetadataContext;
+};
+export declare const initialManifestContext: CustomElementManifestPluginContext;
+export {};

package/dist/manifests/customElementDecoratorPlugins.d.ts

@@ -0,0 +1,58 @@
+/**
+ * In order to have TypeScript be aware of your custom elements, the following
+ * needs to be present inside the library:
+ *
+ * ```ts
+ * declare global {
+ *  interface DeclareElements {
+ *      "arcgis-your-component": ArcgisYourComponent;
+ *   }
+ * }
+ * ```
+ *
+ * We can't simply add this at build time, as the above needs to be present
+ * when your IDE or the CI type-checks the project.
+ *
+ * While we could add the above in a central components.d.ts file like with
+ * Stencil, doing so may cause merge conflicts, would require having a compiler
+ * running in the background to regenerate components.d.ts on change, and can
+ * accidentally cause stale components.d.ts to be committed (if developer forgot
+ * to run the build process before committing)
+ *
+ * So instead, we will add "declare global" inside of each component file.
+ *
+ * To minimize boilerplate, we are going to auto-add the `@customElement()`
+ * decorator at build time since the "declare global" structure above has
+ * the necessary information (the tag name and the class name), and since
+ * decorators don't affect the runtime behavior of the component.
+ *
+ * While "declare global" is helpful for type checking the project itself,
+ * for external typings, we remove it and add component declarations in
+ * dist/index.d.ts file (along with event types and etc). This is to match
+ * Stencil's behavior in order to minimize breaking changes on migration to
+ * Lit.
+ *
+ * FEATURE: for usages in tests, allow `static override tagName = "te-st";` to define a component? and adapt transformers and plugins to look for nested components too when context.isInTest
+ */
+import type { Plugin as ManifestPlugin } from "@custom-elements-manifest/analyzer";
+import type { FileTransformer } from "../publicTypes";
+import type { CompilerContext } from "../context";
+/**
+ * The manifest creation process is using ts.SourceFile instances created
+ * by generateTypes() plugin rather than the transform() hooks (to have
+ * access to the AST and types).
+ * And, to make sure plugins can get access to the final manifest as soon as
+ * possible, the manifest generation process is running before any file
+ * transform().
+ * At the same time, the manifest generation is not aware of our web
+ * components because `@customElement()` decorators are not present yet
+ * (will be added in transform() hook in vite plugin below). So we have to
+ * manually augment "moduleDoc.exports" in this plugin, and later on add the
+ * `@customElement()` decorator in the vite plugin.
+ */
+export declare const addCustomElementDecoratorManifestPlugin: (context: CompilerContext) => ManifestPlugin;
+export declare const addCustomElementDecoratorTransformer: FileTransformer;
+export declare function findDeclaredComponents(code: string): (readonly [tagName: string, className: string])[] | undefined;
+export declare const exportsForTests: {
+    findDeclaredComponents: typeof findDeclaredComponents;
+};

package/dist/manifests/customElementDecoratorPlugins.spec.d.ts

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

package/dist/manifests/hideUntilHydrated.d.ts

@@ -0,0 +1,15 @@
+import type { CompilerContext } from "../context";
+export declare function addGlobalCss(context: CompilerContext): 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: CompilerContext): string;
+/**
+ * Get a CSS string that can be printed into a .css file
+ */
+export declare const getGlobalCssAsString: (context: CompilerContext) => string;

package/dist/manifests/index.d.ts

@@ -0,0 +1,12 @@
+import type { Plugin as VitePlugin } from "vite";
+import type { CompilerContext } from "../context";
+/**
+ * Generate component structure manifest.
+ * Generate entrypoint for lazy-loading components.
+ *
+ * The manifest is then used by componentTransformPipeline() and by
+ * generateDocs(), among others
+ *
+ * @see https://custom-elements-manifest.open-wc.org/analyzer/getting-started/
+ */
+export declare function generateManifest(context: CompilerContext): VitePlugin;

package/dist/manifests/kebabCaseAttributes.d.ts

@@ -0,0 +1,18 @@
+import type { ComponentManifest } from "./utils";
+/**
+ * By default lit converts property names to attributes to get an attribute name.
+ * That is consistent with native DOM attributes.
+ *
+ * However, that is not consistent with Stencil and would be a breaking change
+ * for us. Also, kebab-case is more common among the web components. But the
+ * most important reason is that we have some pretty long attribute names,
+ * which would be utterly unreadable in lowercase.
+ * Also, if browsers add new attributes, that may cause a conflict with our
+ * attributes.
+ *
+ * Thus, in the runtime code, we overwrote Lit's default behavior to use
+ * kebab-case.
+ *
+ * This plugin updates the manifest file to reflect that change
+ */
+export declare function makeAttributesKebabCaseByDefault(customElement: ComponentManifest): void;

package/dist/manifests/lazy.d.ts

@@ -0,0 +1,22 @@
+import type { ComponentManifest } from "./utils";
+import type { CompilerContext } from "../context";
+import type { HmrComponentMeta } from "@arcgis/lumina";
+/**
+ * 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 buildLoaderJs(context: CompilerContext): string;
+export declare const loaderDts = "import \"./index\";\nexport declare const defineCustomElements: import(\"@arcgis/lumina\").DefineCustomElements;";
+/**
+ * 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<ComponentManifest, "members" | "tagName">): string;
+export declare function buildLazyBeta(customElement: Pick<ComponentManifest, "members" | "tagName">): HmrComponentMeta;
+export declare const exportsForTests: {
+    buildCompactLazyMeta: typeof buildCompactLazyMeta;
+};
+export {};

package/dist/manifests/lazy.spec.d.ts

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

package/dist/manifests/stencilManifest.d.ts

@@ -0,0 +1,17 @@
+import type { JsonDocs } from "@stencil/core/internal";
+import type { CompilerContext } from "../context";
+/**
+ * Create a stencil-compatible docs.json manifest.
+ * While custom-elements-manifest is the most popular community standard and is
+ * natively supported by Storybook and other tools, Esri has several internal
+ * tools that expect the Stencil-style docs.json manifest.
+ * Since they are similar in content, generating a Stencil-compatible manifest
+ * will smooth the migration path.
+ *
+ * @remarks
+ * To make it easier for people to diff the docs.json before and after migration
+ * to Lit, we make sure that the order of properties matches what Stencil
+ * generates:
+ * https://github.com/ionic-team/stencil/blob/9f5f9cdd023b8c8dfb5417a1a970605ba724ae28/src/compiler/docs/generate-doc-data.ts#L98
+ */
+export declare const generateStencilManifest: (context: CompilerContext) => JsonDocs;

package/dist/manifests/storybookManifest.d.ts

@@ -0,0 +1,6 @@
+import type { ExtendedComponentManifest } from "./complexTypes/types";
+/**
+ * Providing custom elements manifest to Storybook.
+ * See https://github.com/storybookjs/storybook/tree/next/code/addons/docs/web-components
+ */
+export declare function buildStorybookManifestSetter(manifest: ExtendedComponentManifest): string;

package/dist/manifests/types.d.ts

@@ -0,0 +1 @@
+export type ManifestType = "manifest" | "stencilLikeDocsJson" | "vsCodeCss" | "vsCodeHtml" | "webTypes";

package/dist/manifests/utils.d.ts

@@ -0,0 +1,17 @@
+import type { Package, Module, ClassLike } from "custom-elements-manifest/schema";
+import ts from "typescript";
+import type { ExtendedManifestCustomElement, ExtendedManifestField, ExtendedManifestMethod } from "./complexTypes/types";
+/**
+ * Custom element object in the manifest may be accessed at different stages
+ * of the analysis - some properties (even requires ones) may be missing at
+ * earlier stage of the analysis. That is why Partial<> is used.
+ */
+export type ComponentManifest = ClassLike & Partial<ExtendedManifestCustomElement>;
+/**
+ * Find all custom elements in a module
+ */
+export declare const extractCustomElements: (module: Partial<Module>, strict?: boolean) => ComponentManifest[];
+export declare function findComponent(componentName: string | undefined, moduleDoc: Partial<Module>): ComponentManifest | undefined;
+export declare function findMember(component: ComponentManifest, memberNode: ts.AccessorDeclaration | ts.MethodDeclaration | ts.PropertyDeclaration): ExtendedManifestField | ExtendedManifestMethod | undefined;
+export declare function getMemberName(memberNode: ts.AccessorDeclaration | ts.MethodDeclaration | ts.PropertyDeclaration): string | undefined;
+export declare function findFileManifest(filePath: string, rootDir: string, manifest: Package): Module | undefined;

package/dist/plugins/buildCdn.d.ts

@@ -0,0 +1,14 @@
+import type { Plugin } from "vite";
+import type { CompilerContext } from "../context";
+/**
+ * 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";
+/**
+ * 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;

package/dist/plugins/buildStencilHydrate.d.ts

@@ -0,0 +1,16 @@
+import type { Plugin } from "vite";
+import type { CompilerContext } from "../context";
+/**
+ * Emit output compatible with Stencil's dist-hydrate-script build.
+ *
+ * Based on https://github.com/ionic-team/stencil/blob/main/src/compiler/output-targets/dist-hydrate-script/write-hydrate-outputs.ts
+ *
+ * @deprecated
+ * This option should be used to smooth the migration path from Stencil.
+ * You should instruct your SSR users to migrate to Lit's SSR implementation,
+ * and then stop using this option.
+ *
+ * @see https://stenciljs.com/docs/hydrate-app
+ * @see https://lit.dev/docs/ssr/overview/
+ */
+export declare function buildStencilHydrate(context: CompilerContext): Plugin | undefined;

package/dist/plugins/buildWrappers.d.ts

@@ -0,0 +1,3 @@
+import type { Plugin } from "vite";
+import type { CompilerContext } from "../context";
+export declare function buildWrappers(context: CompilerContext): Plugin;

package/dist/plugins/configureVite.d.ts

@@ -0,0 +1,19 @@
+import type { Plugin } from "vite";
+import type { CompilerContext } from "../context";
+import type { PuppeteerLaunchOptions } from "puppeteer";
+import type { InlineConfig } from "vitest/node";
+export type PuppeteerVitestConfigOptions = InlineConfig & {
+    puppeteerLaunchOptions?: PuppeteerLaunchOptions;
+};
+/**
+ * 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

@@ -0,0 +1,34 @@
+import type { Plugin } from "vite";
+import type { Nil } from "@arcgis/components-utils";
+import type { CompilerContext } from "../context";
+/**
+ * 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;
+export declare const exportsForTests: {
+    normalizeGlobs: (option: Nil | RegExp | string | false) => RegExp | undefined;
+};

package/dist/plugins/externalizeDependencies.spec.d.ts

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

package/dist/plugins/generateDocs.d.ts

@@ -0,0 +1,10 @@
+import type { CompilerContext } from "../context";
+import type { Plugin } from "vite";
+/**
+ * Generate JSON component metadata in 4 formats ()
+ *  - community standard
+ *  - Stencil-like format
+ *  - VS Code standard
+ *  - JetBrains standard
+ */
+export declare function generateDocs(context: CompilerContext): Plugin;

package/dist/plugins/handleDynamicAssets.d.ts

@@ -0,0 +1,3 @@
+import type { Plugin } from "vite";
+import type { CompilerContext } from "../context";
+export declare const handleDynamicAssets: (context: CompilerContext) => Plugin;

package/dist/plugins/handleStaticAssets.d.ts

@@ -0,0 +1,9 @@
+import type { Plugin } from "vite";
+import type { CompilerContext } from "../context";
+/**
+ * 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;