@webjsdev/cli 0.10.46 → 0.10.47

package/bin/webjs.js

@@ -497,28 +497,31 @@ async function main() {
       break;
     }
     case 'ui': {
-      // Delegate to @webjsdev/ui. Bundled as a hard dependency of
-      // @webjsdev/cli, so `npm install -g webjsdev` pulls it in
-      // automatically, and `webjs ui add button` works out of the box
-      // without an extra install in user projects.
-      const { createRequire } = await import('node:module');
-      const req = createRequire(import.meta.url);
+      // Delegate to @webjsdev/ui's bin. It is a hard dependency of
+      // @webjsdev/cli, so `npm install -g webjsdev` pulls it in automatically
+      // and `webjs ui add button` works without an extra install.
+      //
+      // Resolve via resolveBin, NOT req.resolve('@webjsdev/ui/bin/webjsui.js'):
+      // the ui package's `exports` map does not list the bin subpath, so a
+      // direct subpath resolve throws ERR_PACKAGE_PATH_NOT_EXPORTED even though
+      // the file exists, which surfaced as a misleading "could not be resolved"
+      // (#1073). resolveBin resolves the `.` export, walks to the package root,
+      // and reads the `bin` map, exactly as `db` / `test --browser` do.
       let entry;
       try {
-        entry = req.resolve('@webjsdev/ui/bin/webjsui.js');
+        // Hard-dep path: @webjsdev/ui in the CLI's own node_modules.
+        entry = resolveBin(join(__dirname, '..'), '@webjsdev/ui', 'webjsui');
       } catch {
-        // Fallback: try resolving from the user's cwd in case of weird
-        // workspace setups.
+        // Fallback: the user installed @webjsdev/ui directly in their project.
         try {
-          const userReq = createRequire(join(process.cwd(), 'package.json'));
-          entry = userReq.resolve('@webjsdev/ui/bin/webjsui.js');
+          entry = resolveBin(process.cwd(), '@webjsdev/ui', 'webjsui');
         } catch {
           console.error('@webjsdev/ui could not be resolved.');
           console.error('Reinstall the CLI:  npm install -g webjsdev');
           process.exit(1);
         }
       }
-      const child = spawn('node', [entry, ...rest], { stdio: 'inherit', cwd: process.cwd() });
+      const child = spawn(process.execPath, [entry, ...rest], { stdio: 'inherit', cwd: process.cwd() });
       child.on('exit', (code) => process.exit(code ?? 0));
       break;
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@webjsdev/cli",
-  "version": "0.10.46",
+  "version": "0.10.47",
   "type": "module",
   "description": "webjs CLI - dev, start, create, db",
   "bin": {

package/templates/.agents/skills/webjs/references/styling.md

@@ -91,11 +91,11 @@ html`<button class=${buttonClass({ variant: 'secondary', size: 'sm' })} @click=$
 
 Why a class helper (not a `<ui-button>` wrapper): it adds NO indirection, so the element stays native (`@click`, `?disabled`, form submission, focus, a11y all just work) and the markup stays readable, while every button shares one source of truth (so no button can forget `cursor-pointer` or drift). Put the affordance every variant needs (like `cursor-pointer`) on the shared BASE.
 
-**Own and theme your copy.** `webjs ui add <name>` copies the primitive INTO your `components/ui/`, so you own it. Theme it to YOUR app: change the class values so the helper produces YOUR look, rather than bending your app to the kit's defaults. Keep only the parts you use (the gallery's `cardClass` is surface-only, since its panels vary their own padding and layout). Reserve `lib/utils/ui.ts` `html`-fragment helpers for repeated markup chunks; reserve `components/ui/*` class helpers for themed primitives with variants.
+**Default: `webjs ui add`, then modify. Do not hand-write a primitive from scratch.** For a repeated primitive with variants, run `webjs ui add <name>` then trim and theme the copied source. The scaffold already ships the `cn` prerequisite at `lib/utils/cn.ts`, so `add` works out of the box (a non-scaffold app runs `webjs ui init` once first to write `components.json`, the `cn` util, and the design tokens). The kit is shadcn-style, so `add` COPIES the helper's source INTO your `components/ui/` and you own and edit it exactly as freely as code you typed yourself. That is the key point: `add`-then-modify and hand-writing end at the SAME place (owned, editable class-helper source), so the difference is only the STARTING POINT. `add` starts you from vetted, variant-complete source you then adapt (and the copied header spells out the primitive's accessibility obligations), where hand-writing starts from a blank file and re-derives all of it for no benefit. Theme it to YOUR app (change the class values so the helper produces YOUR look, rather than bending your app to the kit's defaults) and keep only the parts you use (the gallery's `cardClass` is surface-only, since its panels vary their own padding and layout). Hand-author a primitive yourself ONLY for a one-off the kit does not cover, or a deliberate opt-out of the kit. Reserve `lib/utils/ui.ts` `html`-fragment helpers for repeated markup chunks; reserve `components/ui/*` class helpers for themed primitives with variants.
 
 ## Accessible native controls
 
-A cleared, growing app hand-authors its own controls, so accessibility is your job (the `@webjsdev/ui` primitives carry their own, but a raw `<button>` / `<input>` does not). Three habits keep hand-authored interactive markup accessible on BOTH the JS and no-JS paths:
+Even with the kit, an app hand-authors SOME markup (a one-off primitive the kit does not cover, or the native element you wrap a class helper around), and there accessibility is your job (the `@webjsdev/ui` primitives carry their own, but a raw `<button>` / `<input>` does not). Three habits keep hand-authored interactive markup accessible on BOTH the JS and no-JS paths:
 
 - **Associate a label with its control.** `<label for="email">` paired with `<input id="email">` (or wrap the control in the `<label>`), so a click on the label focuses the field and a screen reader announces it.
 - **State a toggle's pressed state.** A button that toggles carries `aria-pressed=${on}` so assistive tech announces on/off, not just "button".

package/templates/.agents/skills/webjs/references/ui-kit.md

@@ -1,8 +1,13 @@
 # The `@webjsdev/ui` component kit
 
-Load this when the app has a `components.json` (it uses `@webjsdev/ui`, the
-shadcn-style kit for WebJs). The source is copied into your repo (`components/ui/`),
-so you own and edit it. Two tiers:
+Load this when the app uses `@webjsdev/ui` (a `components.json` is present), OR
+when you are about to add a UI primitive (button, card, input, badge) to a fresh
+app that has not initialised the kit yet: running `webjs ui init` then
+`webjs ui add <name>` is HOW the kit comes to exist, and it is the default for a
+repeated primitive over hand-writing one from scratch. `@webjsdev/ui` is the shadcn-style
+kit for WebJs. The source is copied into your repo (`components/ui/`), so you own
+and edit it exactly as freely as code you wrote yourself (the copied file is
+yours to trim and theme). Two tiers:
 
 - **Tier 1, class helpers (23 components).** Pure functions returning Tailwind
   class strings (`buttonClass({ variant })`, `cardClass()`), composed with

package/templates/AGENTS.md

@@ -43,7 +43,8 @@ The order matters:
    under `components/`, features under `modules/<feature>/`, server-only code
    behind `.server.ts`. Build the app's OWN design system from the blank slate:
    define design tokens in `app/layout.ts` and pull primitives with
-   `npx webjsdev ui add <name>`, following
+   `npx webjsdev ui add <name>` then theme the copied source (you own it, so
+   modify it rather than hand-writing a primitive from scratch), following
    `.agents/skills/webjs/references/styling.md`.
 
 If you are only exploring, keep the gallery and browse it.