@ui-organized/angular 0.0.0-stage → 6.0.0

package/dist/types/ui-organized-angular-icons-heroicons.d.ts

@@ -0,0 +1,53 @@
+import { IconSet as IconSet$1, RegisterIconsOptions } from '@ui-organized/core';
+
+/**
+ * This package's icon-set registry: the shared mechanism from
+ * `@ui-organized/core`, bound to **SVG markup** rather than to components.
+ *
+ * The registry itself — why it exists, why it is keyed on `globalThis`, and why
+ * each framework gets its own — is documented in core. All that happens here is
+ * fixing the stored type, and choosing a key distinct from the other three
+ * packages' so none of them can read another's icons.
+ *
+ * ── Why an Angular icon is a string ─────────────────────────────────────────
+ *
+ * The other three libraries store components, and Angular could too — but
+ * Angular instantiates a component onto an element of its own, so an icon
+ * rendered that way comes out as
+ * `<span class="icon"><ng-icon><svg/></ng-icon></span>` where the others render
+ * `<span class="icon"><svg/></span>`. `.icon` is `display: inline-flex` with
+ * centring, so the intermediate element becomes the flex item and the SVG stops
+ * being what is laid out. One element deeper is a different DOM, and this whole
+ * package exists to produce the same one.
+ *
+ * Core's registry is generic over the stored type precisely so a framework can
+ * answer this differently. Storing markup lets `Icon` create the `<svg>` itself
+ * and put it directly inside the span.
+ *
+ * It also turns out to be the *better* contract for stroke. Every
+ * `@ng-icons/*` pack ships its icons with
+ * `style="stroke-width:var(--ng-icon__stroke-width, 2)"`, so a single custom
+ * property drives the weight for lucide, tabler and heroicons alike — where the
+ * React adapters need three different prop shapes because lucide takes
+ * `strokeWidth`, tabler takes `stroke` and heroicons takes `width`/`height`.
+ */
+type IconMarkup = string;
+type IconSet = IconSet$1<IconMarkup>;
+
+declare const heroiconsIcons: IconSet;
+/**
+ * Make Heroicons icons available to `<Icon name>` under their own names.
+ *
+ * Pass them as imported and the names follow from the exports
+ * (`heroCamera` → `"camera"`), or key them by native name yourself where
+ * the export can't be read back unambiguously (`{ h1: heroH1 }`).
+ * Only what you register reaches your bundle.
+ *
+ * ```ts
+ * import { heroCamera, heroRocketLaunch } from "@ng-icons/heroicons/outline";
+ * registerIcons({ heroCamera, heroRocketLaunch });
+ * ```
+ */
+declare function registerIcons(icons: Record<string, IconMarkup>, options?: RegisterIconsOptions): void;
+
+export { heroiconsIcons, registerIcons };

package/dist/types/ui-organized-angular-icons-lucide.d.ts

@@ -0,0 +1,53 @@
+import { IconSet as IconSet$1, RegisterIconsOptions } from '@ui-organized/core';
+
+/**
+ * This package's icon-set registry: the shared mechanism from
+ * `@ui-organized/core`, bound to **SVG markup** rather than to components.
+ *
+ * The registry itself — why it exists, why it is keyed on `globalThis`, and why
+ * each framework gets its own — is documented in core. All that happens here is
+ * fixing the stored type, and choosing a key distinct from the other three
+ * packages' so none of them can read another's icons.
+ *
+ * ── Why an Angular icon is a string ─────────────────────────────────────────
+ *
+ * The other three libraries store components, and Angular could too — but
+ * Angular instantiates a component onto an element of its own, so an icon
+ * rendered that way comes out as
+ * `<span class="icon"><ng-icon><svg/></ng-icon></span>` where the others render
+ * `<span class="icon"><svg/></span>`. `.icon` is `display: inline-flex` with
+ * centring, so the intermediate element becomes the flex item and the SVG stops
+ * being what is laid out. One element deeper is a different DOM, and this whole
+ * package exists to produce the same one.
+ *
+ * Core's registry is generic over the stored type precisely so a framework can
+ * answer this differently. Storing markup lets `Icon` create the `<svg>` itself
+ * and put it directly inside the span.
+ *
+ * It also turns out to be the *better* contract for stroke. Every
+ * `@ng-icons/*` pack ships its icons with
+ * `style="stroke-width:var(--ng-icon__stroke-width, 2)"`, so a single custom
+ * property drives the weight for lucide, tabler and heroicons alike — where the
+ * React adapters need three different prop shapes because lucide takes
+ * `strokeWidth`, tabler takes `stroke` and heroicons takes `width`/`height`.
+ */
+type IconMarkup = string;
+type IconSet = IconSet$1<IconMarkup>;
+
+declare const lucideIcons: IconSet;
+/**
+ * Make Lucide icons available to `<Icon name>` under their own Lucide names.
+ *
+ * Pass them as imported and the names follow from the exports
+ * (`lucideCamera` → `"camera"`), or key them by native name yourself where
+ * the export can't be read back unambiguously (`{ "arrow-down-0-1": lucideArrowDown01 }`).
+ * Only what you register reaches your bundle.
+ *
+ * ```ts
+ * import { lucideCamera, lucideRocket } from "@ng-icons/lucide";
+ * registerIcons({ lucideCamera, lucideRocket });
+ * ```
+ */
+declare function registerIcons(icons: Record<string, IconMarkup>, options?: RegisterIconsOptions): void;
+
+export { lucideIcons, registerIcons };

package/dist/types/ui-organized-angular-icons-tabler.d.ts

@@ -0,0 +1,53 @@
+import { IconSet as IconSet$1, RegisterIconsOptions } from '@ui-organized/core';
+
+/**
+ * This package's icon-set registry: the shared mechanism from
+ * `@ui-organized/core`, bound to **SVG markup** rather than to components.
+ *
+ * The registry itself — why it exists, why it is keyed on `globalThis`, and why
+ * each framework gets its own — is documented in core. All that happens here is
+ * fixing the stored type, and choosing a key distinct from the other three
+ * packages' so none of them can read another's icons.
+ *
+ * ── Why an Angular icon is a string ─────────────────────────────────────────
+ *
+ * The other three libraries store components, and Angular could too — but
+ * Angular instantiates a component onto an element of its own, so an icon
+ * rendered that way comes out as
+ * `<span class="icon"><ng-icon><svg/></ng-icon></span>` where the others render
+ * `<span class="icon"><svg/></span>`. `.icon` is `display: inline-flex` with
+ * centring, so the intermediate element becomes the flex item and the SVG stops
+ * being what is laid out. One element deeper is a different DOM, and this whole
+ * package exists to produce the same one.
+ *
+ * Core's registry is generic over the stored type precisely so a framework can
+ * answer this differently. Storing markup lets `Icon` create the `<svg>` itself
+ * and put it directly inside the span.
+ *
+ * It also turns out to be the *better* contract for stroke. Every
+ * `@ng-icons/*` pack ships its icons with
+ * `style="stroke-width:var(--ng-icon__stroke-width, 2)"`, so a single custom
+ * property drives the weight for lucide, tabler and heroicons alike — where the
+ * React adapters need three different prop shapes because lucide takes
+ * `strokeWidth`, tabler takes `stroke` and heroicons takes `width`/`height`.
+ */
+type IconMarkup = string;
+type IconSet = IconSet$1<IconMarkup>;
+
+declare const tablerIcons: IconSet;
+/**
+ * Make Tabler icons available to `<Icon name>` under their own Tabler names.
+ *
+ * Pass them as imported and the names follow from the exports
+ * (`tablerCamera` → `"camera"`), or key them by native name yourself where
+ * the export can't be read back unambiguously (`{ "crop-16-9": tablerCrop169 }`).
+ * Only what you register reaches your bundle.
+ *
+ * ```ts
+ * import { tablerCamera, tablerRocket } from "@ng-icons/tabler-icons";
+ * registerIcons({ tablerCamera, tablerRocket });
+ * ```
+ */
+declare function registerIcons(icons: Record<string, IconMarkup>, options?: RegisterIconsOptions): void;
+
+export { registerIcons, tablerIcons };