@loomidev/icons 0.5.0 → 0.7.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +11 -11
  2. package/package.json +1 -1
package/README.md CHANGED
@@ -2,13 +2,13 @@
2
2
 
3
3
  The shared icon registry used across loomi components, covering three sources:
4
4
 
5
- - **`heroicons`** (default) — generated from the official Heroicons 24px outline and
5
+ - **`heroicons`** (default) - generated from the official Heroicons 24px outline and
6
6
  solid sets, then published as plain Lit SVG templates inlined directly into this
7
7
  package. No React or Heroicons runtime dependency ships to consumers.
8
- - **`iconsax`** and **`untitledui`** — disk-based. Unlike Heroicons, these are loaded one
8
+ - **`iconsax`** and **`untitledui`** - disk-based. Unlike Heroicons, these are loaded one
9
9
  icon at a time rather than inlined as JS strings. A consumer using one icon from a
10
- 3,800-icon set only ever loads that one icon — resolved once, cached in memory for the
11
- rest of the page's lifetime — instead of every component on the page paying for the
10
+ 3,800-icon set only ever loads that one icon - resolved once, cached in memory for the
11
+ rest of the page's lifetime - instead of every component on the page paying for the
12
12
  whole set up front. They ship twice: as per-icon ES modules under
13
13
  `dist/icons/<source>/<type>/<name>.js`, and as the original `.svg` files under
14
14
  `dist/svg/<source>/<type>/<name>.svg`.
@@ -41,7 +41,7 @@ is available everywhere.
41
41
  ## Iconsax and Untitled UI (disk-based)
42
42
 
43
43
  Most consumers should just use `<loomi-icon source="iconsax" name="…">` (see
44
- [`@loomidev/icon`](../icon)) rather than calling these directly — they exist so other
44
+ [`@loomidev/icon`](../icon)) rather than calling these directly - they exist so other
45
45
  components can adopt the same sources later the way they already do for Heroicons.
46
46
 
47
47
  | Source | Types |
@@ -52,17 +52,17 @@ components can adopt the same sources later the way they already do for Heroicon
52
52
  | Export | Description |
53
53
  | ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
54
54
  | `loadLoomiDiskIcon(source, name, type?)` | Loads (and caches) the icon, resolving to a value renderable directly inside a Lit `html` template: `` html`<svg>${await loadLoomiDiskIcon(...)}</svg>` ``. Resolves `undefined` for an unregistered name or a failed load. |
55
- | `hasLoomiDiskIcon(source, name, type?)` | Whether the name is a real icon. Synchronous — it only consults the name manifest, and loads nothing. |
55
+ | `hasLoomiDiskIcon(source, name, type?)` | Whether the name is a real icon. Synchronous - it only consults the name manifest, and loads nothing. |
56
56
  | `registerLoomiDiskIcon(source, name, markup, type?)` | Register a statically imported icon so it renders with no network request and no dynamic chunk. See [Static imports](#static-imports). |
57
57
  | `setLoomiIconBasePath(path)` | Serve the raw `.svg` files from a path you control instead of loading the modules. See [Serving the SVGs yourself](#serving-the-svgs-yourself). Pass `undefined` to go back to modules. |
58
58
  | `getLoomiIconBasePath()` | The base path currently set, or `undefined` when icons load from the generated modules. |
59
59
  | `getLoomiDiskIconUrl(source, name, type?)` | Resolves to the icon's `.svg` URL, or `undefined` if `name` isn't registered. An unavailable `type` for that source (e.g. `untitledui` + `"twotone"`) falls back to `outline` rather than failing. |
60
60
  | `loomiDiskIconNames(source, type?)` | List all registered names for a source/type. |
61
61
  | `loomiDiskIconTypes(source)` | List the types a source actually ships, e.g. `["outline", "solid", "twotone"]` for `iconsax`. |
62
- | `isLoomiDiskIconSource(source)` | Type guard — `true` for `"iconsax"` / `"untitledui"`, `false` for `"heroicons"`. |
62
+ | `isLoomiDiskIconSource(source)` | Type guard - `true` for `"iconsax"` / `"untitledui"`, `false` for `"heroicons"`. |
63
63
 
64
64
  All disk-based icons are normalized to `fill`/`stroke="currentColor"` at import time (see
65
- `scripts/import-icon-set.mjs`), so they theme exactly like Heroicons do — no per-icon
65
+ `scripts/import-icon-set.mjs`), so they theme exactly like Heroicons do - no per-icon
66
66
  color prop needed.
67
67
 
68
68
  ### How an icon is resolved
@@ -71,20 +71,20 @@ color prop needed.
71
71
 
72
72
  1. **A statically registered icon**, if you registered one for that name.
73
73
  2. **A fetch from your base path**, if you called `setLoomiIconBasePath`.
74
- 3. **The generated per-icon module** — `import("./icons/iconsax/outline/home.js")`.
74
+ 3. **The generated per-icon module** - `import("./icons/iconsax/outline/home.js")`.
75
75
 
76
76
  Step 3 is the default because it is the only one that survives a bundler. Every specifier
77
77
  in the generated loader index is a string literal, so webpack, Vite, Rollup, esbuild, and
78
78
  Parcel all trace and code-split them, and the consuming app needs no asset-copying step.
79
79
 
80
80
  The raw `.svg` files still ship, and resolve on their own wherever the package keeps its
81
- real module URL — a CDN, an import map, or a plain `<script type="module">`. What they
81
+ real module URL - a CDN, an import map, or a plain `<script type="module">`. What they
82
82
  cannot survive is bundling: a bundler inlines this module into a chunk and never copies
83
83
  `dist/svg/`, so a relative asset URL would 404. That is what steps 2 and 3 exist for.
84
84
 
85
85
  ### Static imports
86
86
 
87
- Importing an icon directly is the leanest option — no runtime lookup, no dynamic chunk,
87
+ Importing an icon directly is the leanest option - no runtime lookup, no dynamic chunk,
88
88
  and dead icons drop out of the bundle:
89
89
 
90
90
  ```ts
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@loomidev/icons",
3
- "version": "0.5.0",
3
+ "version": "0.7.0",
4
4
  "description": "Shared icon registry for loomi components: an inlined Heroicons set plus disk-based Iconsax and Untitled UI icon sets, with a runtime register API.",
5
5
  "repository": {
6
6
  "type": "git",