@blotch/angular-lynx-build 0.0.0-stage → 22.2.3

package/builders/rspeedy.js

@@ -0,0 +1,162 @@
+"use strict";
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.createRspeedy = exports.modeFromOptimization = exports.importQRCodePlugin = exports.importPlugin = exports.importRspeedy = void 0;
+const node_fs_1 = require("node:fs");
+const node_path_1 = __importDefault(require("node:path"));
+/**
+ * Like the rsbuild plugin, rspeedy is this package's own dependency, so the
+ * builders always run the rspeedy version they were released and tested with,
+ * and an app needs no build tool in its package.json besides this package
+ * (as one from `ng new` needs only `@angular/build`).
+ */
+const importRspeedy = () => import('@lynx-js/rspeedy');
+exports.importRspeedy = importRspeedy;
+/**
+ * Unlike rspeedy, the plugin is this package's own dependency, so it is
+ * resolved from here rather than from the project: the builders always run
+ * the plugin version they were released with.
+ */
+const importPlugin = () => import('@blotch/rsbuild-plugin-angular-lynx');
+exports.importPlugin = importPlugin;
+const importQRCodePlugin = () => import('@lynx-js/qrcode-rsbuild-plugin');
+exports.importQRCodePlugin = importQRCodePlugin;
+/** The name `pluginAngularLynx()` registers itself under. */
+const ANGULAR_PLUGIN_NAME = 'lynx:angular';
+/** The name `pluginQRCode()` registers itself under. */
+const QR_CODE_PLUGIN_NAME = 'lynx:rsbuild:qrcode';
+/**
+ * The files rspeedy looks for when no `config` option names one, in its order
+ * (`resolveConfigPath` in @lynx-js/rspeedy).
+ */
+const DEFAULT_CONFIG_FILES = [
+    'lynx.config.ts',
+    'lynx.config.js',
+    'lynx.config.mts',
+    'lynx.config.mjs',
+];
+/**
+ * Whether an rspeedy `plugins` list holds the plugin named `name`. The list
+ * takes Rsbuild's shapes: plugins, falsy entries (from `cond && plugin()`),
+ * promises of either, and nested lists.
+ */
+const hasPlugin = async (plugins, name) => {
+    const plugin = await plugins;
+    if (Array.isArray(plugin)) {
+        for (const item of plugin) {
+            if (await hasPlugin(item, name)) {
+                return true;
+            }
+        }
+        return false;
+    }
+    return plugin?.name === name;
+};
+/**
+ * The rspeedy mode for a build target's options. Angular has no mode option:
+ * its `optimization` decides, and a build that doesn't optimize scripts runs
+ * in dev mode (`ngDevMode` on). The same switch picks rspeedy's mode, so
+ * `ng build -c development` (`optimization: false`) is a development build
+ * and `ng serve -c production` a production one.
+ */
+const modeFromOptimization = (optimization) => {
+    // Angular's own reading of the option (normalizeOptimization in
+    // @angular/build): on by default, and in object form `scripts` decides.
+    const scripts = typeof optimization === 'object' && optimization !== null
+        ? !!optimization.scripts
+        : optimization !== false;
+    return scripts ? 'production' : 'development';
+};
+exports.modeFromOptimization = modeFromOptimization;
+/**
+ * Loads lynx.config.ts as `rspeedy build` and `rspeedy dev` would. Unlike
+ * them, a project without one builds too, from the defaults
+ * {@link createRspeedy} fills in: angular.json holds what the config would
+ * repeat, as it does for any Angular app. A `config` option must name a file
+ * that exists.
+ */
+const loadProjectConfig = async (rspeedy, projectRoot, config) => {
+    if (!config &&
+        !DEFAULT_CONFIG_FILES.some((file) => (0, node_fs_1.existsSync)(node_path_1.default.join(projectRoot, file)))) {
+        return { content: {} };
+    }
+    return rspeedy.loadConfig({ cwd: projectRoot, configPath: config });
+};
+/**
+ * Creates an rspeedy instance the way `rspeedy build` and `rspeedy dev` do:
+ * load lynx.config.ts, then apply the command-line overrides, which here come
+ * from the builder options.
+ *
+ * What lynx.config.ts leaves out comes from angular.json and the defaults an
+ * AngularLynx app needs, so most apps don't need the file at all:
+ *
+ * - `source.entry` is the build target's `browser` option.
+ * - `environments` are `lynx` (the native bundle) and `web` (the browser
+ *   preview).
+ * - The mode follows the build target's `optimization` (see
+ *   {@link modeFromOptimization}).
+ *
+ * It also adds plugins, each unless lynx.config.ts lists it itself (to pass
+ * it options): the AngularLynx plugin, which compiles Angular, and for the
+ * dev server the QR code plugin, which prints the link Lynx Explorer opens.
+ * And the Angular CLI context plugin hands the AngularLynx plugin the project
+ * and its build options as Angular CLI resolved them (`-c` and command-line
+ * overrides included), which it would otherwise read from angular.json under
+ * the default configuration.
+ */
+const createRspeedy = async ({ rspeedy, plugin, qrCode, projectRoot, angularCli, config, environment, server, }) => {
+    const mode = (0, exports.modeFromOptimization)(angularCli.buildOptions['optimization']);
+    // As the rspeedy CLI does before anything else, so plugins (Tailwind,
+    // PostCSS) that read NODE_ENV agree with the mode. The CLI derives it from
+    // the command; here the mode decides, as `optimization` does for Angular.
+    if (!process.env['NODE_ENV']) {
+        process.env['NODE_ENV'] = mode;
+    }
+    const { content, configPath } = await loadProjectConfig(rspeedy, projectRoot, config);
+    // As `rspeedy build` does: a persistent build cache must be invalidated
+    // when lynx.config.ts itself changes.
+    const performance = content['performance'];
+    if (configPath) {
+        if (performance?.buildCache === true) {
+            performance.buildCache = { buildDependencies: [configPath] };
+        }
+        else if (performance?.buildCache) {
+            (performance.buildCache.buildDependencies ??= []).push(configPath);
+        }
+    }
+    content.mode = mode;
+    content['environments'] ??= { lynx: {}, web: {} };
+    const browser = angularCli.buildOptions['browser'];
+    const source = (content['source'] ??= {});
+    if (source.entry === undefined && typeof browser === 'string') {
+        source.entry = node_path_1.default.join(angularCli.workspaceRoot, browser);
+    }
+    if (server?.port !== undefined || server?.host !== undefined) {
+        content['server'] = {
+            ...content['server'],
+            ...(server.port !== undefined && { port: server.port }),
+            ...(server.host !== undefined && { host: server.host }),
+        };
+    }
+    const plugins = Array.isArray(content['plugins']) ? content['plugins'] : [];
+    content['plugins'] = [
+        plugin.pluginAngularCliContext(angularCli),
+        ...plugins,
+        ...((await hasPlugin(plugins, ANGULAR_PLUGIN_NAME))
+            ? []
+            : [plugin.pluginAngularLynx()]),
+        // `fullscreen` opens the app in Lynx Explorer without its navigation
+        // bar, as the rspeedy project template does.
+        ...(qrCode && !(await hasPlugin(plugins, QR_CODE_PLUGIN_NAME))
+            ? [qrCode.pluginQRCode({ fullscreen: true })]
+            : []),
+    ];
+    return rspeedy.createRspeedy({
+        cwd: projectRoot,
+        rspeedyConfig: content,
+        environment: environment ?? [],
+    });
+};
+exports.createRspeedy = createRspeedy;

package/builders/unit-test/index.js

@@ -0,0 +1,96 @@
+"use strict";
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.runUnitTest = exports.hasTestingLibrary = void 0;
+const architect_1 = require("@angular-devkit/architect");
+const node_module_1 = require("node:module");
+const node_path_1 = __importDefault(require("node:path"));
+const angular_build_1 = require("../angular-build");
+/**
+ * Whether the project has @blotch/angular-lynx-testing-library. Its package.json
+ * isn't in its `exports` in every version, and Node then refuses to resolve
+ * it, but only when the package is there.
+ */
+const hasTestingLibrary = (projectRoot) => {
+    try {
+        (0, node_module_1.createRequire)(node_path_1.default.join(projectRoot, 'package.json')).resolve('@blotch/angular-lynx-testing-library/package.json');
+        return true;
+    }
+    catch (error) {
+        return (error.code === 'ERR_PACKAGE_PATH_NOT_EXPORTED');
+    }
+};
+exports.hasTestingLibrary = hasTestingLibrary;
+const defaultDeps = {
+    importAngularBuild: (projectRoot) => (0, angular_build_1.importAngularBuild)(projectRoot),
+    hasTestingLibrary: exports.hasTestingLibrary,
+};
+/**
+ * The options as Angular CLI hands them to Angular's own builders. For a
+ * builder outside `@angular/build`, it sets every array option the user left
+ * out to `[]` (and nested ones too, e.g. `coverageWatermarks.lines`), which
+ * Angular's unit-test builder reads as set: `reporters: []` runs Vitest with
+ * no reporter, so `ng test` printed nothing. An empty list never means more
+ * than an absent one here, so empty lists are dropped.
+ */
+const withoutEmptyLists = (value) => {
+    if (typeof value !== 'object' || value === null || Array.isArray(value)) {
+        return value;
+    }
+    return Object.fromEntries(Object.entries(value)
+        .filter(([, item]) => !(Array.isArray(item) && item.length === 0))
+        .map(([key, item]) => [key, withoutEmptyLists(item)]));
+};
+/**
+ * `ng test`: Angular's unit-test builder (`@angular/build:unit-test`), so the
+ * options, test discovery (`*.spec.ts` and `*.test.ts`), TestBed, watch mode
+ * and coverage are the ones Angular developers know, and the tests compile
+ * ahead of time like the app. Two modules load first: one defines the
+ * compile-time flags the AngularLynx runtime reads, and, when the project has
+ * @blotch/angular-lynx-testing-library, its setup prepares the Lynx
+ * environment its `render()` needs.
+ *
+ * Tests render through Angular's DOM renderer under TestBed and through the
+ * Lynx renderer under the testing library's `render()`. Either way the test
+ * compile checks templates strictly, as the Angular Language Service does:
+ * a component that uses Lynx elements imports LYNX_ELEMENTS (as generated
+ * ones do). The app build is laxer, because it adds CUSTOM_ELEMENTS_SCHEMA to
+ * every component, which Angular's test build has no hook for.
+ */
+const runUnitTest = async function* (options, context, deps = defaultDeps) {
+    const projectName = context.target?.project;
+    if (!projectName) {
+        yield { success: false, error: 'The builder needs a project target.' };
+        return;
+    }
+    const metadata = await context.getProjectMetadata(projectName);
+    const projectRoot = node_path_1.default.join(context.workspaceRoot, metadata['root'] ?? '');
+    let angularBuild;
+    try {
+        angularBuild = await deps.importAngularBuild(projectRoot);
+    }
+    catch (error) {
+        yield {
+            success: false,
+            error: error instanceof Error ? error.message : String(error),
+        };
+        return;
+    }
+    // The Lynx setup goes in as polyfills rather than `setupFiles` because
+    // Angular compiles setup files with the tests, and TypeScript rejects one
+    // outside the tsconfig's folder when the tsconfig sets an `outDir`, as
+    // `ng new`'s tsconfig.spec.json does: a package in the workspace's
+    // node_modules is outside a project in `projects/`. Polyfills are bundled
+    // as modules, and run first.
+    const lynxPolyfills = [
+        '@blotch/angular-lynx-build/unit-test/lynx-globals',
+        ...(deps.hasTestingLibrary(projectRoot)
+            ? ['@blotch/angular-lynx-testing-library/setup']
+            : []),
+    ];
+    yield* angularBuild.executeUnitTestBuilder(withoutEmptyLists(options), (0, angular_build_1.asAngularBuildTargets)(context, lynxPolyfills));
+};
+exports.runUnitTest = runUnitTest;
+exports.default = (0, architect_1.createBuilder)((options, context) => (0, exports.runUnitTest)(options, context));

package/builders/unit-test/lynx-globals.d.mts

@@ -0,0 +1,3 @@
+// lynx-globals.mjs only sets globals: `ng test` loads it for its side
+// effects, as a polyfill. Declared so type checkers (and attw) see the module.
+export {};

package/builders/unit-test/lynx-globals.mjs

@@ -0,0 +1,18 @@
+// The first module `ng test` loads, as a polyfill: before Angular's TestBed,
+// the testing library's setup, and any test that imports @blotch/angular-lynx.
+//
+// The runtime reads these compile-time flags, which the rsbuild plugin
+// defines for each thread when it bundles the app. Angular's unit-test build
+// leaves packages unbundled, so a `define` couldn't reach the runtime's code;
+// globals do. Tests run the way the native main thread does: in development,
+// not on the web, without profiling or SSR.
+//
+// Plain JavaScript, so it isn't compiled to CommonJS with the builders:
+// Angular bundles polyfills as ES modules.
+Object.assign(globalThis, {
+  __DEV__: true,
+  __MAIN_THREAD__: true,
+  __WEB__: false,
+  __PROFILE__: false,
+  __ENABLE_SSR__: false,
+});

package/builders/unit-test/schema.js

@@ -0,0 +1,2 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });

package/builders/unit-test/schema.json

@@ -0,0 +1,311 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema",
+  "$id": "AngularLynxUnitTestBuilder",
+  "title": "AngularLynx unit-test builder",
+  "description": "Runs the unit tests with Angular's unit-test builder (@angular/build:unit-test), set up for AngularLynx. The options are Angular's: this file copies its schema.json, and a test keeps the two in step.",
+  "type": "object",
+  "properties": {
+    "buildTarget": {
+      "type": "string",
+      "description": "Specifies the build target to use for the unit test build in the format `project:target[:configuration]`. This defaults to the `build` target of the current project with the `development` configuration. You can also pass a comma-separated list of configurations. Example: `project:target:production,staging`.",
+      "pattern": "^[^:\\s]*:[^:\\s]*(:[^\\s]+)?$"
+    },
+    "tsConfig": {
+      "type": "string",
+      "description": "The path to the TypeScript configuration file, relative to the workspace root. Defaults to `tsconfig.spec.json` in the project root if it exists. If not specified and the default does not exist, the `tsConfig` from the specified `buildTarget` will be used."
+    },
+    "runner": {
+      "type": "string",
+      "description": "Specifies the test runner to use for test execution.",
+      "default": "vitest",
+      "enum": ["karma", "vitest"]
+    },
+    "runnerConfig": {
+      "type": ["string", "boolean"],
+      "description": "Specifies the configuration file for the selected test runner. If a string is provided, it will be used as the path to the configuration file. If `true`, the builder will search for a default configuration file (e.g., `vitest-base.config.mts` or `karma.conf.js`). If `false`, no external configuration file will be used.\\nFor Vitest, this enables advanced options and the use of custom plugins. Please note that while the file is loaded, the Angular team does not provide direct support for its specific contents or any third-party plugins used within it.",
+      "default": false
+    },
+    "browsers": {
+      "description": "Specifies the browsers to use for test execution. When not specified, tests are run in a Node.js environment using jsdom. For both Vitest and Karma, browser names ending with 'Headless' (e.g., 'ChromeHeadless') will enable headless mode.",
+      "type": "array",
+      "items": {
+        "type": "string"
+      },
+      "minItems": 1
+    },
+    "browserViewport": {
+      "description": "Specifies the browser viewport dimensions for browser-based tests in the format `widthxheight`.",
+      "type": "string",
+      "pattern": "^\\d+x\\d+$"
+    },
+    "include": {
+      "type": "array",
+      "items": {
+        "type": "string"
+      },
+      "default": ["**/*.spec.ts", "**/*.test.ts"],
+      "description": "Specifies glob patterns of files to include for testing, relative to the project source root. This option also has special handling for directory paths (includes all test files within) and file paths (includes the corresponding test file if one exists)."
+    },
+    "exclude": {
+      "type": "array",
+      "items": {
+        "type": "string"
+      },
+      "description": "Specifies glob patterns of files to exclude from testing, relative to the project source root."
+    },
+    "filter": {
+      "type": "string",
+      "description": "Specifies a regular expression pattern to match against test suite and test names. Only tests with a name matching the pattern will be executed. For example, `^App` will run only tests in suites beginning with 'App'."
+    },
+    "watch": {
+      "type": "boolean",
+      "description": "Enables watch mode, which re-runs tests when source files change. Defaults to `true` in TTY environments and `false` otherwise."
+    },
+    "headless": {
+      "type": "boolean",
+      "description": "Forces all configured browsers to run in headless mode. When using the Vitest runner, this option is ignored if no browsers are configured. The Karma runner does not support this option."
+    },
+    "debug": {
+      "type": "boolean",
+      "description": "Enables debugging mode for tests, allowing the use of the Node Inspector.",
+      "default": false
+    },
+    "ui": {
+      "type": "boolean",
+      "description": "Enables the Vitest UI for interactive test execution. This option is only available for the Vitest runner."
+    },
+    "isolate": {
+      "type": "boolean",
+      "description": "Enables isolation for test execution. When true, Vitest runs tests in separate threads or processes. This option is only available for the Vitest runner. Defaults to false to align with the Karma/Jasmine experience."
+    },
+    "splitting": {
+      "type": "boolean",
+      "description": "Enables code splitting for test execution. When enabled, shared code between test files is split into separate chunks. Issues with live ESM bindings in Node.js environments (such as uninitialized exports or mocking failures) can be resolved by disabling splitting. This option is only available for the Vitest runner.",
+      "default": true,
+      "x-deprecated": "No longer needed with Vitest 5."
+    },
+    "quiet": {
+      "type": "boolean",
+      "description": "Suppresses the verbose build summary and stats table on each rebuild. Defaults to `true` locally and `false` in CI environments."
+    },
+    "coverage": {
+      "type": "boolean",
+      "description": "Enables coverage reporting for tests. If not specified, the coverage configuration from a runner configuration file will be used if present. Otherwise, coverage is disabled by default."
+    },
+    "coverageInclude": {
+      "type": "array",
+      "description": "Specifies glob patterns of files to include in the coverage report.",
+      "items": {
+        "type": "string"
+      }
+    },
+    "coverageExclude": {
+      "type": "array",
+      "description": "Specifies glob patterns of files to exclude from the coverage report.",
+      "items": {
+        "type": "string"
+      }
+    },
+    "coverageReporters": {
+      "type": "array",
+      "description": "Specifies the reporters to use for coverage results. Each reporter can be a string representing its name, or a tuple containing the name and an options object. Built-in reporters include 'html', 'lcov', 'lcovonly', 'text', 'text-summary', 'cobertura', 'json', and 'json-summary'.",
+      "items": {
+        "oneOf": [
+          {
+            "enum": [
+              "html",
+              "lcov",
+              "lcovonly",
+              "text",
+              "text-summary",
+              "cobertura",
+              "json",
+              "json-summary"
+            ]
+          },
+          {
+            "type": "array",
+            "minItems": 1,
+            "maxItems": 2,
+            "items": [
+              {
+                "enum": [
+                  "html",
+                  "lcov",
+                  "lcovonly",
+                  "text",
+                  "text-summary",
+                  "cobertura",
+                  "json",
+                  "json-summary"
+                ]
+              },
+              {
+                "type": "object"
+              }
+            ]
+          }
+        ]
+      }
+    },
+    "coverageThresholds": {
+      "type": "object",
+      "description": "Specifies minimum coverage thresholds that must be met. If thresholds are not met, the builder will exit with an error.",
+      "properties": {
+        "perFile": {
+          "type": "boolean",
+          "description": "When true, thresholds are enforced for each file individually."
+        },
+        "statements": {
+          "type": "number",
+          "description": "Minimum percentage of statements covered."
+        },
+        "branches": {
+          "type": "number",
+          "description": "Minimum percentage of branches covered."
+        },
+        "functions": {
+          "type": "number",
+          "description": "Minimum percentage of functions covered."
+        },
+        "lines": {
+          "type": "number",
+          "description": "Minimum percentage of lines covered."
+        }
+      },
+      "additionalProperties": false
+    },
+    "coverageWatermarks": {
+      "type": "object",
+      "description": "Specifies coverage watermarks for the HTML reporter. These determine the color coding for high, medium, and low coverage.",
+      "properties": {
+        "statements": {
+          "type": "array",
+          "description": "The high and low watermarks for statements coverage. `[low, high]`",
+          "items": {
+            "type": "number"
+          },
+          "minItems": 2,
+          "maxItems": 2
+        },
+        "branches": {
+          "type": "array",
+          "description": "The high and low watermarks for branches coverage. `[low, high]`",
+          "items": {
+            "type": "number"
+          },
+          "minItems": 2,
+          "maxItems": 2
+        },
+        "functions": {
+          "type": "array",
+          "description": "The high and low watermarks for functions coverage. `[low, high]`",
+          "items": {
+            "type": "number"
+          },
+          "minItems": 2,
+          "maxItems": 2
+        },
+        "lines": {
+          "type": "array",
+          "description": "The high and low watermarks for lines coverage. `[low, high]`",
+          "items": {
+            "type": "number"
+          },
+          "minItems": 2,
+          "maxItems": 2
+        }
+      },
+      "additionalProperties": false
+    },
+    "reporters": {
+      "type": "array",
+      "description": "Specifies the reporters to use during test execution. Each reporter can be a string representing its name, or a tuple containing the name and an options object. Built-in reporters include 'default', 'verbose', 'dots', 'json', 'junit', 'tap', 'tap-flat', and 'html'. You can also provide a path to a custom reporter.",
+      "items": {
+        "oneOf": [
+          {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "enum": [
+                  "default",
+                  "verbose",
+                  "dots",
+                  "json",
+                  "junit",
+                  "tap",
+                  "tap-flat",
+                  "html"
+                ]
+              }
+            ]
+          },
+          {
+            "type": "array",
+            "minItems": 1,
+            "maxItems": 2,
+            "items": [
+              {
+                "anyOf": [
+                  {
+                    "type": "string"
+                  },
+                  {
+                    "enum": [
+                      "default",
+                      "verbose",
+                      "dots",
+                      "json",
+                      "junit",
+                      "tap",
+                      "tap-flat",
+                      "html"
+                    ]
+                  }
+                ]
+              },
+              {
+                "type": "object"
+              }
+            ]
+          }
+        ]
+      }
+    },
+    "outputFile": {
+      "type": "string",
+      "description": "Specifies a file path for the test report, applying only to the first reporter. To configure output files for multiple reporters, use the tuple format `['reporter-name', { outputFile: '...' }]` within the `reporters` option. When not provided, output is written to the console."
+    },
+    "providersFile": {
+      "type": "string",
+      "description": "Specifies the path to a TypeScript file that provides an array of Angular providers for the test environment. The file must contain a default export of the provider array.",
+      "minLength": 1
+    },
+    "setupFiles": {
+      "type": "array",
+      "items": {
+        "type": "string"
+      },
+      "description": "A list of paths to global setup files that are executed before the test files. The application's polyfills and the Angular TestBed are always initialized before these files."
+    },
+    "progress": {
+      "type": "boolean",
+      "description": "Shows build progress information in the console. Defaults to the `progress` setting of the specified `buildTarget`."
+    },
+    "listTests": {
+      "type": "boolean",
+      "description": "Lists all discovered test files and exits the process without building or executing the tests.",
+      "default": false
+    },
+    "dumpVirtualFiles": {
+      "type": "boolean",
+      "description": "Dumps build output files to the `.angular/cache` directory for debugging purposes.",
+      "default": false,
+      "visible": false
+    }
+  },
+  "additionalProperties": false,
+  "required": []
+}

package/client.d.ts

@@ -0,0 +1,8 @@
+// Types for what the bundler handles in app code: asset and CSS module
+// imports, `import.meta.env`, `import.meta.webpackHot`. Apps reference them
+// from here (`/// <reference types="@blotch/angular-lynx-build/client" />`)
+// rather than from rspeedy, which is this package's dependency, not theirs:
+// under strict package managers (pnpm, Yarn PnP) the app couldn't resolve it.
+/// <reference types="@lynx-js/rspeedy/client" />
+
+export {};

package/dist/index.d.ts

@@ -0,0 +1,15 @@
+/**
+ * The rsbuild plugin `ng build` and `ng serve` apply, for a lynx.config.ts
+ * that passes it options or runs under plain rspeedy. A config that lists it
+ * keeps that instance; otherwise the builders add `pluginAngularLynx()`
+ * themselves. Re-exported so the import works with strict package managers
+ * (pnpm, Yarn PnP), where the plugin is a dependency of this package rather
+ * than of the app.
+ */
+export * from '@blotch/rsbuild-plugin-angular-lynx';
+/**
+ * rspeedy's config helper, for the same reason: rspeedy is this package's
+ * dependency, so an app's lynx.config.ts imports it from here.
+ */
+export { defineConfig } from '@lynx-js/rspeedy';
+export type { Config } from '@lynx-js/rspeedy';

package/dist/index.js

@@ -0,0 +1,14 @@
+/**
+ * The rsbuild plugin `ng build` and `ng serve` apply, for a lynx.config.ts
+ * that passes it options or runs under plain rspeedy. A config that lists it
+ * keeps that instance; otherwise the builders add `pluginAngularLynx()`
+ * themselves. Re-exported so the import works with strict package managers
+ * (pnpm, Yarn PnP), where the plugin is a dependency of this package rather
+ * than of the app.
+ */
+export * from '@blotch/rsbuild-plugin-angular-lynx';
+/**
+ * rspeedy's config helper, for the same reason: rspeedy is this package's
+ * dependency, so an app's lynx.config.ts imports it from here.
+ */
+export { defineConfig } from '@lynx-js/rspeedy';