---
title: "CLI Changelog"
description: "Notable @glasshome/widget-cli releases and the Hub-enforced minimum version."
canonical: https://glasshome.app/docs/widgets/cli-changelog
section: "CLI & Publishing"
updated: 2026-08-16
---
# CLI Changelog

Highlights of `@glasshome/widget-cli`; the entry-by-entry history lives in the [CLI CHANGELOG](https://github.com/glasshome/widget-cli/blob/main/CHANGELOG.md). The SDK ships separately: see the [SDK changelog](/docs/widgets/changelog).

## Notable CLI releases

### 0.11: upgrade upgrades

- `upgrade` in a standalone project now moves the SDK for you: `bun add @glasshome/widget-sdk@latest` (or `--to <version>`) into the section that already declares it, then the manifest `sdkVersion` sync and `validate` it always did. Before, it only synced manifests and printed the four manual steps.
- Fresh projects build again on Windows and get `@glasshome/ui` on install; both fixes ship in widget-sdk 1.10.3, which `create` now scaffolds against.

### 0.10: types checked, compatibility told the truth

- `build` and `publish` typecheck the project first and stop on a type error. Scaffolded projects ran a bare `vite build`, which strips types without checking them, so a widget could publish with its config type and its `configSchema` disagreeing. Projects without TypeScript are not blocked, only warned.
- New widgets no longer scaffold a stale `sdkVersion`. `create` and `add` wrote a hardcoded `^0.2.0` while the project built against a 1.x SDK, and because a pre-1.0 range reads as "pre-capabilities", those widgets were quietly excused from declaring [capabilities](/docs/widgets/widget-capabilities) at all. The range is now derived from the SDK you actually have installed.
- `validate` compares the manifest range against the installed SDK instead of the range in `package.json`, which only ever compared a claim with itself. `publish` runs the same check, where it was previously skipped.
- `publish` sends the manifest written by the build it just ran, so bundle-owned keys no longer ship one publish behind.

### 0.9: preview shots

- `glasshome-widget preview` renders every `examples` entry from your manifest, light and dark, into `preview/`, using the same harness the Hub's render worker uses. See [Widget Previews](/docs/widgets/widget-previews).
- Playwright is an optional peer: without it the command prints the install line instead of failing.

### 0.8: update and compatibility warnings

- Every command nudges when a newer CLI is published, checked at most once a day and cached, so warm runs stay offline. Opt out with `GLASSHOME_NO_UPDATE_NOTIFIER` or `CI`.
- `validate` warns when a manifest's `sdkVersion` range excludes the SDK pinned in `package.json`.
- `login` stores the Hub-assigned username as your publish scope, so the scope shown at login matches what `publish` uses.

### 0.6: config migration

- `migrate config` rewrites a widget's raw-zod config to the SDK config API (`defineConfig` + `field.*`). Unrecognized patterns are left alone and reported. `--dry` previews; `--name <widget>` targets one widget. See [Config API](/docs/widgets/widget-sdk/config).
- `build` and `connect` lint for deprecated config usage and direct `zod` imports, printing the removal timeline. Warning only.

## Minimum version

Hub enforces a minimum CLI version per deploy; publishing with an older CLI is refused. The current floor is served from `/api/widgets/cli-version`. See [Widget CLI](/docs/widgets/widget-cli#version-requirements).

## Releases

[`@glasshome/widget-cli` on npm](https://www.npmjs.com/package/@glasshome/widget-cli)