Skip to content

fix(ui-website): align @webjskit/* deps to workspace versions#35

Merged
vivek7405 merged 1 commit into
mainfrom
fix/ui-website-workspace-deps
May 20, 2026
Merged

fix(ui-website): align @webjskit/* deps to workspace versions#35
vivek7405 merged 1 commit into
mainfrom
fix/ui-website-workspace-deps

Conversation

@vivek7405
Copy link
Copy Markdown
Collaborator

Root cause

packages/ui/packages/website/package.json pinned old framework versions:

"@webjskit/cli": "^0.5.2",
"@webjskit/core": "^0.4.1",
"@webjskit/server": "^0.5.2",

The workspaces are at 0.6.0, 0.5.0, 0.6.0. Caret on a 0.x version is patch-only (^0.5.2 means >=0.5.2 <0.6.0), so the workspace did not satisfy the range. npm installed published tarballs from the registry into packages/ui/node_modules/@webjskit/* and skipped the workspace symlink.

Production therefore ran the published @webjskit/server@0.5.2, whose TypeScript serving path is esbuild-only. esbuild's multi-class declaration transform has a known bug where every <ui-dialog-*> sub-tag rendered with UiDialog's shell (data-slot="dialog" data-state="closed") instead of its own. The local fix (Node 24+ native module.stripTypeScriptTypes first, esbuild fallback only on ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX) shipped in @webjskit/server@0.6.0 but the website never picked it up.

What changed

Bumped the three ranges to the current workspace versions so npm links the local workspace instead of pulling stale tarballs. package-lock.json regenerated to drop packages/ui/node_modules/@webjskit/{cli,core,server}.

Verification

Local npm start in the website now serves /components/ui/dialog.ts at 13780 bytes with no sourceMappingURL (native strip-types output, position-preserving whitespace replacement) instead of the previous 31748 bytes of esbuild output. SSR for <ui-dialog> now renders each sub-element with its own shell.

Test plan

  • npm install resolves @webjskit/server to the workspace, not the registry tarball
  • Website's npm start serves dialog.ts via strip-types (no sourceMappingURL)
  • SSR of /docs/components/dialog shows data-slot="dialog-trigger", dialog-native, dialog-close (each sub-element renders its own shell)
  • Deploy and re-test https://ui.webjs.dev/docs/components/dialog

ui-website pinned `@webjskit/server: ^0.5.2`, `@webjskit/core: ^0.4.1`,
`@webjskit/cli: ^0.5.2` while the monorepo workspaces are at 0.6.0,
0.5.0, 0.6.0. npm therefore installed published 0.5.x tarballs into
packages/ui/node_modules/@webjskit/* and skipped the workspace
symlink (caret on 0.x is patch-only, so ^0.5.2 excludes 0.6.0).

Production ran the published 0.5.2 server, whose TypeScript path is
esbuild-only and has the multi-class declaration transform that
collapses every <ui-dialog-*> sub-element into UiDialog's render()
shell (the bug Node-24 native strip-types was meant to fix).
@vivek7405 vivek7405 force-pushed the fix/ui-website-workspace-deps branch from 0bf7d4d to 4efacf4 Compare May 20, 2026 22:48
@vivek7405 vivek7405 merged commit 61a25fa into main May 20, 2026
@vivek7405 vivek7405 deleted the fix/ui-website-workspace-deps branch May 20, 2026 22:48
vivek7405 added a commit that referenced this pull request May 20, 2026
* release: bump core/server/cli/ui for lit-API parity + Tier-2 rewrite

  @webjskit/core   0.5.0 -> 0.6.0  (lit-API parity, ReactiveController hooks,
                                    full lifecycle, lit-html directives, SSR
                                    property bindings)
  @webjskit/server 0.6.0 -> 0.7.0  (split .server.ts source-protection from
                                    'use server' RPC marker, WEBJS_PUBLIC_*
                                    browser env, new lint rules)
  @webjskit/cli    0.6.0 -> 0.7.0  (inter-package dep ranges updated)
  @webjskit/ui     stays at 0.2.0  (Tier-2 components rewritten on
                                    WebComponent + render() + <slot>;
                                    bumped locally already, never published)

Inter-package dep ranges:
  server -> core:    ^0.5.0 -> ^0.6.0
  cli    -> server:  ^0.6.0 -> ^0.7.0
  cli    -> ui:      "0.1.0" (pinned) -> ^0.2.0

Downstream consumer manifests (website, docs, examples/blog,
packages/ui/packages/website) bumped to the new ranges so workspace
resolution keeps the local sources linked instead of pulling stale
tarballs from the registry (the failure mode that broke ui.webjs.dev
in #35).

* docs(scaffold): inline lit muscle-memory gotchas

Scaffolded apps don't receive the framework's agent-docs/ folder, so a
URL pointer would leave AI agents working in a scaffolded app a fetch
away from the catalog of lit patterns that break in webjs.

Add a condensed gotchas section to the scaffold AGENTS.md inline:
the per-behavior-opt-in mental model (contrasting webjs against lit's
per-component hydration), and a 9-row quick-reference table covering
the failure modes (broken SSR, silent reactivity, styling, lifecycle
hooks that don't run server-side). The full annotated catalog with
code examples still lives in the framework repo and is linked from
the section.

Placed right after the Component pattern section so agents read it
when they're already in component-authoring context, before reaching
for lit idioms.
vivek7405 added a commit that referenced this pull request May 21, 2026
Three packages have user-facing changes accumulated since their
last bump:

- @webjskit/core 0.6.0 -> 0.7.0
  Breaking: signals replace this.state / setState across the
  stack (#43). Slot projection cycle fix in light DOM (#44).
- @webjskit/cli 0.7.0 -> 0.8.0
  Scaffold templates updated for the signals migration (#43); a
  newly-scaffolded app now ships signal-based state out of the
  box and the scaffold tests assert the new shape.
- @webjskit/ui 0.2.0 -> 0.3.0
  Env-driven sibling URLs with localhost dev fallbacks (#42),
  workspace dep alignment (#35), signal migration in the
  registry components and ui-website (#43), and the responsive
  mobile menu / changelog page that landed alongside the
  changelog system (#49).

Cross-package dependency ranges in website, docs, examples/blog,
ui-website, server, and cli updated to track the new versions
(^0.6.0 -> ^0.7.0 for core, ^0.7.0 -> ^0.8.0 for cli, ^0.2.0 ->
^0.3.0 for ui). package-lock.json regenerated.

After this lands on main, the Auto-release workflow will publish
all three to npm and create matching GitHub Releases.
vivek7405 added a commit that referenced this pull request May 21, 2026
ui-website pinned `@webjskit/server: ^0.5.2`, `@webjskit/core: ^0.4.1`,
`@webjskit/cli: ^0.5.2` while the monorepo workspaces are at 0.6.0,
0.5.0, 0.6.0. npm therefore installed published 0.5.x tarballs into
packages/ui/node_modules/@webjskit/* and skipped the workspace
symlink (caret on 0.x is patch-only, so ^0.5.2 excludes 0.6.0).

Production ran the published 0.5.2 server, whose TypeScript path is
esbuild-only and has the multi-class declaration transform that
collapses every <ui-dialog-*> sub-element into UiDialog's render()
shell (the bug Node-24 native strip-types was meant to fix).
vivek7405 added a commit that referenced this pull request May 21, 2026
* release: bump core/server/cli/ui for lit-API parity + Tier-2 rewrite

  @webjskit/core   0.5.0 -> 0.6.0  (lit-API parity, ReactiveController hooks,
                                    full lifecycle, lit-html directives, SSR
                                    property bindings)
  @webjskit/server 0.6.0 -> 0.7.0  (split .server.ts source-protection from
                                    'use server' RPC marker, WEBJS_PUBLIC_*
                                    browser env, new lint rules)
  @webjskit/cli    0.6.0 -> 0.7.0  (inter-package dep ranges updated)
  @webjskit/ui     stays at 0.2.0  (Tier-2 components rewritten on
                                    WebComponent + render() + <slot>;
                                    bumped locally already, never published)

Inter-package dep ranges:
  server -> core:    ^0.5.0 -> ^0.6.0
  cli    -> server:  ^0.6.0 -> ^0.7.0
  cli    -> ui:      "0.1.0" (pinned) -> ^0.2.0

Downstream consumer manifests (website, docs, examples/blog,
packages/ui/packages/website) bumped to the new ranges so workspace
resolution keeps the local sources linked instead of pulling stale
tarballs from the registry (the failure mode that broke ui.webjs.dev
in #35).

* docs(scaffold): inline lit muscle-memory gotchas

Scaffolded apps don't receive the framework's agent-docs/ folder, so a
URL pointer would leave AI agents working in a scaffolded app a fetch
away from the catalog of lit patterns that break in webjs.

Add a condensed gotchas section to the scaffold AGENTS.md inline:
the per-behavior-opt-in mental model (contrasting webjs against lit's
per-component hydration), and a 9-row quick-reference table covering
the failure modes (broken SSR, silent reactivity, styling, lifecycle
hooks that don't run server-side). The full annotated catalog with
code examples still lives in the framework repo and is linked from
the section.

Placed right after the Component pattern section so agents read it
when they're already in component-authoring context, before reaching
for lit idioms.
vivek7405 added a commit that referenced this pull request May 21, 2026
Three packages have user-facing changes accumulated since their
last bump:

- @webjskit/core 0.6.0 -> 0.7.0
  Breaking: signals replace this.state / setState across the
  stack (#43). Slot projection cycle fix in light DOM (#44).
- @webjskit/cli 0.7.0 -> 0.8.0
  Scaffold templates updated for the signals migration (#43); a
  newly-scaffolded app now ships signal-based state out of the
  box and the scaffold tests assert the new shape.
- @webjskit/ui 0.2.0 -> 0.3.0
  Env-driven sibling URLs with localhost dev fallbacks (#42),
  workspace dep alignment (#35), signal migration in the
  registry components and ui-website (#43), and the responsive
  mobile menu / changelog page that landed alongside the
  changelog system (#49).

Cross-package dependency ranges in website, docs, examples/blog,
ui-website, server, and cli updated to track the new versions
(^0.6.0 -> ^0.7.0 for core, ^0.7.0 -> ^0.8.0 for cli, ^0.2.0 ->
^0.3.0 for ui). package-lock.json regenerated.

After this lands on main, the Auto-release workflow will publish
all three to npm and create matching GitHub Releases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant