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

package/dist/puppeteerTesting/globalSetup.d.ts

@@ -1,73 +0,0 @@
-import { TestProject } from 'vitest/node';
-import { ConnectOptions } from 'puppeteer';
-declare module "vitest" {
-    interface ProvidedContext {
-        isDevToolsEnabled?: boolean;
-        isHeadlessBrowser?: boolean;
-        devServerHtml?: string;
-        devServerUrl?: string;
-        puppeteerConnectOptions?: ConnectOptions;
-        puppeteerWaitForChangesDelay?: number;
-    }
-}
-/**
- * Global setup file for Vitest Puppeteer integration.
- *
- * This is run once, in the main thread, before any tests are run.
- *
- * We start browser via Puppeteer so that tests can render to it and interact
- * with it.
- *
- * In the browser, we render the test suite. The browser sends requests for
- * JavaScript files to the Vite dev server.
- *
- * We start that Vite dev server in this file too. It is separate from the
- * Vite dev server started by Vitest.
- *
- * It has to be separate because Vitest's dev server resolves imports for the
- * "node" import condition. If we instead tell Vitest to use browser export
- * conditions, then Lit's "isServer" will be false both in browser and node.js,
- * potentially breaking some components. While happy-dom is neat, it does match
- * the actual browser API 100%. It is safer to run a separate Vite instance for
- * Node.js (Vitest) and browser. This is a short-term issue anyway as we are
- * looking to moving to Vitest browser mode feature, that would resolve this
- * issue.
- *
- * Here is an example Vite configuration plugin that is needed if you wish to
- * make Vitest's Vite instance somewhat usable directly by Playwright's browser:
- * ```ts
- * config: (config) => {
- *   const conditions = config.resolve?.conditions;
- *   // Remove "node" condition.
- *   // Can't do this imperatively as Vite's default configuration merging only
- *   // allows adding settings, not removing.
- *   if (conditions && conditions.includes("node")) {
- *     conditions.splice(conditions.indexOf("node"), 1);
- *   }
- *   return {
- *     server: {
- *       middlewareMode: false,
- *     },
- *     test: {
- *       api: true,
- *       environment: "happy-dom",
- *     },
- *   };
- * },
- *
- * Vite's upcoming Environment API will make it possible to use a single dev
- * server (https://github.com/vitejs/vite/pull/16089/files). However, we plan
- * to provide Puppeteer integration only temporary to ease the Stencil
- * migration, so optimizing it too much is not a goal.
- */
-export declare function setup(context: TestProject): Promise<() => Promise<void>>;
-export type PuppeteerViteGlobals = {
-    /**
-     * Helps lumina-compiler dev server know that is it running for Puppeteer
-     * browser.
-     *
-     * Not exposing this in global typings for usage in tests because
-     * `import.meta.env.MODE` should be used instead.
-     */
-    __IS_IN_PUPPETEER__?: true;
-};

package/dist/puppeteerTesting/injected.d.ts

@@ -1,8 +0,0 @@
-import { ProvidedContext } from 'vitest';
-/**
- * Convenience wrapper around "inject()" API to improve DX
- *
- * With this "Go to definition" and "refactor -> rename" IDE features work
- * better.
- */
-export declare const injected: ProvidedContext;

package/dist/puppeteerTesting/puppeteer/browser.d.ts

@@ -1,6 +0,0 @@
-import { Browser } from 'puppeteer';
-/**
- * This is called when test is executing in a non-main thread. We connect to
- * the browser instance using a web socket.
- */
-export declare function connectBrowser(): Promise<Browser>;

package/dist/puppeteerTesting/vitest/matchers/attributes.d.ts

@@ -1,4 +0,0 @@
-import { RawMatcherFn } from '@vitest/expect';
-export declare const toEqualAttribute: RawMatcherFn;
-export declare const toEqualAttributes: RawMatcherFn;
-export declare const toHaveAttribute: RawMatcherFn;

package/dist/puppeteerTesting/vitest/matchers/classList.d.ts

@@ -1,4 +0,0 @@
-import { RawMatcherFn, SyncExpectationResult } from '@vitest/expect';
-export declare const toHaveClass: RawMatcherFn;
-export declare const toHaveClasses: (element: unknown, expectClassNames: string[]) => SyncExpectationResult;
-export declare const toMatchClasses: RawMatcherFn;

package/dist/puppeteerTesting/vitest/matchers/events.d.ts

@@ -1,7 +0,0 @@
-import { RawMatcherFn } from '@vitest/expect';
-export declare const toHaveReceivedEvent: RawMatcherFn;
-export declare const toHaveReceivedEventTimes: RawMatcherFn;
-export declare const toHaveReceivedEventDetail: RawMatcherFn;
-export declare const toHaveFirstReceivedEventDetail: RawMatcherFn;
-export declare const toHaveLastReceivedEventDetail: RawMatcherFn;
-export declare const toHaveNthReceivedEventDetail: RawMatcherFn;

package/dist/puppeteerTesting/vitest/matchers/text.d.ts

@@ -1,2 +0,0 @@
-import { RawMatcherFn } from '@vitest/expect';
-export declare const toEqualText: RawMatcherFn;

package/dist/puppeteerTesting/vitest/matchers/utils.d.ts

@@ -1 +0,0 @@
-export declare function assertIsElement(element: unknown, matcherName: string): asserts element is Element;

package/dist/puppeteerTesting/vitest/runner.d.ts

@@ -1,19 +0,0 @@
-import { TestRunner } from 'vitest';
-import { Page } from 'puppeteer';
-import { Suite } from '@vitest/runner';
-/**
- * This has to be default export for Vitest to discover it
- *
- * @see https://github.com/vitest-dev/vitest/blob/699055eb93909287e1542fdfb99d97f2a38965ba/packages/vitest/src/runtime/runners/index.ts#L25
- */
-export default class PuppeteerTestRunner extends TestRunner {
-    private _browser?;
-    private _pages;
-    private _pageCloseExpected;
-    private _browserClosePromise?;
-    constructor(...rest: ConstructorParameters<typeof TestRunner>);
-    createNewPage(): Promise<Page>;
-    private _connectBrowser;
-    private _closeOpenPages;
-    onAfterRunSuite(suite: Suite): Promise<void>;
-}

package/dist/puppeteerTesting/vitest/setupFile.d.ts

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

package/dist/puppeteerTesting/vitest/types.d.ts

@@ -1,6 +0,0 @@
-import { default as PuppeteerTestRunner } from './runner.ts';
-type PuppeteerGlobalThis = typeof globalThis & {
-    runner: PuppeteerTestRunner;
-};
-export declare const puppeteerGlobalThis: PuppeteerGlobalThis;
-export {};

package/dist/testing/failOnConsole.d.ts

@@ -1,6 +0,0 @@
-/**
- * Based on https://github.com/thomasbrodusch/vitest-fail-on-console/, but
- * simplified and with our fixes applied:
- * https://github.com/thomasbrodusch/vitest-fail-on-console/issues/61
- */
-export declare function failOnConsole(): void;

package/dist/testing/setupFile.d.ts

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

package/dist/testing/snapshotSerializer.d.ts

@@ -1,12 +0,0 @@
-/**
- * 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/tests/utils.d.ts

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

package/dist/transformers/customElementDeclaration.d.ts

@@ -1,2 +0,0 @@
-import { FileTransformer } from '../publicTypes.ts';
-export declare const addCustomElementDecoratorTransformer: FileTransformer;

package/dist/transformers/index.d.ts

@@ -1,20 +0,0 @@
-import { Plugin } from 'vite';
-import { CompilerContext } from '../context/index.ts';
-/**
- * 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;

package/dist/transformers/injectRuntimeOptions.d.ts

@@ -1,18 +0,0 @@
-import { CompilerContext } from '../context/index.ts';
-import { Plugin } from 'vite';
-/**
- * Update src/runtime.ts in the component package based on the options specified
- * in the Lumina config. This is done so that all configuration is isolated to
- * the single vite.config.ts file, rather than spread over several files.
- */
-export declare const injectRuntimeOptions: (context: CompilerContext) => Plugin;
-/**
- * Add to chunks/runtime.js import statement for the global CSS file.
- * This way CSS is injected automatically, simplifying get started instructions.
- * We also inject CSS imports for Lumina dependencies this package uses - this
- * is needed to ensure CSS is loaded in correct order - this does not cause
- * duplicate CSS bundling.
- *
- * Research notes: https://devtopia.esri.com/WebGIS/arcgis-web-components/discussions/1824#discussioncomment-12625
- */
-export declare function getGlobalCssImport(context: CompilerContext): string;

package/dist/transformers/liftDecorators.d.ts

@@ -1,21 +0,0 @@
-import { default as 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

@@ -1,10 +0,0 @@
-import { FileTransformer } from '../publicTypes.ts';
-/**
- * - 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;

package/dist/transformers/property.d.ts

@@ -1,10 +0,0 @@
-import { default as ts } from 'typescript';
-import { FileTransformContext } from '../publicTypes.ts';
-import { LiftedDecorators } from './liftDecorators.ts';
-import { ApiCustomElementDeclaration } from '@arcgis/api-extractor/apiJson';
-export declare function transformProperty(context: FileTransformContext, component: ApiCustomElementDeclaration | undefined, property: ts.AccessorDeclaration | ts.PropertyDeclaration, className: string | undefined, sourceFile: ts.SourceFile, liftedDecorators: LiftedDecorators): ts.ClassElement;
-export type ParsedPropertyDecorator = {
-    decorator: ts.Decorator;
-    callExpression: ts.CallExpression;
-    options: ts.ObjectLiteralExpression | undefined;
-};

package/dist/transformers/propertyOptions.d.ts

@@ -1,110 +0,0 @@
-import { default as ts } from 'typescript';
-import { ParsedPropertyDecorator } from './property.ts';
-import { ApiCustomElementField } from '@arcgis/api-extractor/apiJson';
-/**
- * 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(decorator: ParsedPropertyDecorator, sourceFile: ts.SourceFile, apiProperty: ApiCustomElementField): ts.ObjectLiteralExpression | undefined;

package/dist/transformers/utils.d.ts

@@ -1,9 +0,0 @@
-import { default as ts } from 'typescript';
-import { FileTransformContext, FileTransformer } from '../publicTypes.ts';
-import { CompilerContext } from '../context/index.ts';
-/**
- * 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;
-export declare function removeComments(node: ts.Node, context: FileTransformContext): void;