GGitHubchore: Use gpui-kit (#2929)
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
chore: Use gpui-kit (#2929) ## Summary Zed owns the `gpui` crate names on crates.io and publishes them only occasionally. This PR adds `script/bump-gpui.ts` (Bun) to publish a snapshot of any Zed commit to crates.io under our own names, a weekly `Release GPUI` workflow that runs it, and switches the workspace, README and docs to those crates. | Zed crate | Published as | | --- | --- | | `gpui` | `gpui-pre` | | `gpui_platform` | `gpui-pre-platform` | | `gpui_macros` | `gpui-pre-macros` | | `reqwest_client` | `gpui-pre-reqwest-client` | | `gpui_<x>` / other internal crates | `gpui-pre-<x>` | What the script does: - Fetches the requested Zed revision (`--rev`, default `main`) into `target/gpui-pre/zed`, or reuses a checkout passed with `--zed`. - Walks the workspace path dependencies of the four root crates and publishes the whole closure (25 crates today) at one version, `<VERSION>.<N>` (e.g. `0.3.12`): the `VERSION` constant at the top of the script (`0.3`) plus a patch number that continues from the highest one crates.io already has (`0.3.0` first). A run that stopped part-way resumes the same number. A positional argument publishes an explicit version instead. - Keeps each crate's original name as `[lib] name`, so consumers write `gpui = { package = "gpui-pre", version = "0.3.0" }` and `use gpui::*` unchanged; `actions!` and `#[derive(Action)]` keep working. - Drops optional dependencies that come from git without a crates.io version (`proptest`, `async-tar`) together with the features that enable them, then removes optional dependencies nothing can enable any more. This keeps Zed's `util` crate (which needs Zed's git-patched `async-process`) out of the publish set. - Swaps the workspace `reqwest` dependency (Zed's git fork) for the hand-published `gpui-pre-reqwest` through `DEPENDENCY_OVERRIDES`. - Vendors the gpui source files that `gpui_apple`'s build script reads from `../gpui`, since a crate unpacked from crates.io has no such sibling. - Verifies everything with `cargo publish --workspace --dry-run`, then publishes with `cargo publish --workspace`, re-checking crates.io before each attempt and waiting out the new-crate rate limit so a run can be resumed. Workflow: - `.github/workflows/release-gpui.yml` runs the script every other Sunday (even ISO weeks, gated by a small `cadence` job since cron cannot express two weeks) at 18:00 Beijing time (`0 10 * * 0` UTC) and on `workflow_dispatch` with optional `rev` and `version` inputs, on `macos-latest` so `gpui_apple`'s Metal shader build script is verified. It uses the `CARGO_REGISTRY_TOKEN` secret and writes the published crate table to the job summary. Workspace and docs: - `Cargo.toml` now depends on `gpui-pre` 0.3.0 (`gpui`, `gpui_platform`, `gpui_web`, `gpui_macros`, `reqwest_client`, `sum-tree`) and `gpui-pre-reqwest` 0.12.15 instead of the Zed git repository, `zed-sum-tree` and Zed's reqwest fork. The `[profile.dev.package]` overrides follow the new package names. - README (en/zh-CN), the site docs (en/zh-CN), the gpui-component skill, and the crate READMEs show the `gpui-pre` dependency lines. - CONTRIBUTING documents the workflow and version scheme. ## gpui-kit `crates/kit` (published as `gpui-kit`, names already reserved on crates.io) is the one crate applications depend on. It pins the matching `gpui-pre-*` set and re-exports every layer: | Path | Crate | Feature | | --- | --- | --- | | `gpui_kit::gpui` | `gpui` | always | | `gpui_kit::platform` | `gpui_platform` | always | | `gpui_kit::base` | `gpui-base` | always | | `gpui_kit::component` | `gpui-component` | `component` (default) | | `gpui_kit::assets` | `gpui-kit-assets` | `assets` (default) | | `gpui_kit::shell` | `gpui-shell` | `shell` (default) | | `gpui_kit::webview` | `gpui-wry` | `webview` | `gpui_kit::application()` and `gpui_kit::init()` cover startup, and `gpui_kit::prelude::*` also brings the crate names into scope, so `gpui::…` paths and the `actions!` / `#[derive(Action)]` macros (which expand to `gpui::…`) work without a direct `gpui` dependency. The `gpui-component` features (`inspector`, `decimal`, `tree-sitter*`) are forwarded by name. README, the site docs, the skill, the crate READMEs and `hello_world` now show `gpui-kit = "0.6"` alone; the docs no longer link GPUI to gpui.rs. Workspace crates are bumped to 0.6.0. ## Breaking Changes `gpui-component-assets` is renamed `gpui-kit-assets`; the `links` key is unchanged so `gpui-component`'s build script still finds the icon directory. ```diff -gpui-component-assets = "0.5" +gpui-kit-assets = "0.6" ``` ```diff -use gpui_component_assets::Assets; +use gpui_kit_assets::Assets; ``` Applications that listed GPUI themselves can drop those lines: ```diff -gpui = { package = "gpui-pre", version = "0.3.0" } -gpui_platform = { package = "gpui-pre-platform", version = "0.3.0", features = ["font-kit"] } -gpui-component = "0.5" +gpui-kit = "0.6" ``` ## Release gate Before anything is uploaded, `script/bump-gpui.ts` builds and tests this repository against the staged crates (mirrored outside the checkout and injected with `--config patch.crates-io…`; `Cargo.lock` is scratch-updated and restored, and `cargo metadata` proves the patch resolved). CI's `check`, `clippy` and `test` must pass, so a Zed change that no longer fits `gpui-component` fails the release instead of reaching applications through their caret `gpui-pre` requirement on `cargo update`. `--skip-kit-check` bypasses it. The workflow installs the system dependencies for that step. The facade-aware macro rewrite now copies `#[cfg]` gates onto the wrapped bodies (the published 0.3.1 `gpui-pre-macros` breaks release builds without `inspector`; 0.3.2 fixes it) and the `actions!` rewrite is scoped to the `macro_rules!` block. `gpui-shell` is not published for now (its `llrt_*` dependencies are git-only) and is no longer part of `gpui-kit`; `gpui-fps` is. `release.yml` publishes our crates with one ordered `cargo publish -p …`. ## Verification - `./script/bump-gpui.ts --dry-run --zed <local zed checkout>`: all 25 crates package and build; `gpui-pre-reqwest` resolves from crates.io. - With a temporary `[patch.crates-io]` pointing at the staged workspace (not committed), `cargo check --workspace` passes for every crate, story, story-web and example. - A scratch consumer crate depending on the staged crates via `package = "gpui-pre"` passes `cargo check`, including `actions!`, `#[derive(Action)]` and `collections::` by its original lib name. - `gpui-kit`: `cargo check` with default, no, `base`-only, `component`-only and `webview,inspector,tree-sitter-rust` features, its doc tests, `cargo check --workspace`, the CI clippy set plus `gpui-kit` and `hello_world` with `--deny warnings`, and `cargo machete` all pass against the staged `gpui-pre`. - `tsc --strict` with `@types/bun`, `typos`, and a YAML parse of the workflow pass. `gpui-pre` 0.3.0 is not on crates.io yet, so CI cannot resolve dependencies until the `Release GPUI` workflow has run (by hand, or on the next even ISO week Sunday). A requirement of `0.3.0` accepts every later `0.3.x` as well. `Cargo.lock` is left for that first resolution. ## AI assistance The script, workflow, dependency switch and documentation were written with Claude Code and reviewed by hand. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01D2PVGzukYKuXnb3LB5s53T --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> | 27 天前 | |
base: Move TextView to gpui-base (#2881) ## Description `TextView` — the Markdown and HTML renderer, its parser, its inline layout and its selection — lived in `crates/ui`, so a `gpui-base` application could not render rich text without depending on the whole component library. This moves the implementation to `gpui-base` and leaves a compatibility facade behind in `gpui_component::text`. What moved: `document`, `format` (Markdown and HTML), `inline`, `inline_flow`, `markdown_ext`, `node`, `selection`, `selection_adapter`, `state`, `style`, `text_view`, `utils`. What stayed: the component `TextViewStyle`, the `tree-sitter` syntax highlighting, and the theme adapter that maps `gpui_component::Theme` onto the Base style. Base rich text is usable on its own. `TextViewStyle::default()` is a complete, readable style rather than an empty customization bag, and syntax highlighting is opt-in through `code_block_highlighter` so Base keeps no tree-sitter language dependency. ### `gpui-component` is unchanged `gpui_component::text::TextView` keeps every builder, both associated element types, `Text`, `TextViewPlugin`, `markdown()` and `html()`. Existing code compiles as it did: ```rust use gpui_component::text::{TextView, TextViewStyle}; TextView::markdown("readme", source) .style(TextViewStyle::default().table(scrolling_table)) .selectable(true) ``` The facade folds a component style onto the one the active theme already derived, so a caller who set one `StyleRefinement` field keeps the themed padding and colors for the rest. `crates/ui/tests/base_compat.rs` and the `legacy_*` unit tests hold that contract. ### A new `SelectableText` element Plain text that joins the window-scoped selection, for applications that want copyable text without a rich-text document. ## New semantic token: `colors.selection` Selection had been a literal `hsla(0.58, 0.85, 0.62, 0.35)` written out in three places: `TextViewStyle::default()`, the fallback in `Inline::paint`, and `SelectableText::paint`. It is now one semantic token that the component adapter maps from `Theme::selection`, so Base text selection follows the application palette instead of a fixed blue. The field carries a serde default, so palettes written before it existed still deserialize. `TextViewStyle::from_theme` had derived selection as `accent.alpha(0.4)`, which in the default light palette is a near-white wash that barely reads as a selection at all. It now uses the token. ## Breaking Changes Only `gpui-base` is affected. `gpui-component`'s public API is unchanged. `TextViewStyle` crosses the `gpui-base` seam, so its fields are now private with `with_*` builders and accessors of the same name — a later field becomes an additive change instead of a breaking one. ```diff let style = TextViewStyle::default() - .foreground(colors.foreground) - .muted_foreground(colors.muted_foreground) - .link(colors.link) - .selection(colors.selection); - style.code_background = colors.elevated; - style.border = colors.border; - style.is_dark = true; + .with_foreground(colors.foreground) + .with_muted_foreground(colors.muted_foreground) + .with_link(colors.link) + .with_selection(colors.selection) + .with_code_background(colors.elevated) + .with_border(colors.border) + .with_dark(true); - let radius = style.table.corner_radii.top_left; + let radius = style.table().corner_radii.top_left; ``` `TextViewDefaults` follows the same naming: ```diff TextViewDefaults::new() - .style(style) - .code_block_highlighter(highlighter) + .with_style(style) + .with_code_block_highlighter(highlighter) .install(cx); ``` gpui-shell mirrors the Base color tokens in its script API, so `selection` joins them there too. A script that passes a literal token object to `set_theme` must now supply it, the same rule every other color already follows: ```diff set_theme({ appearance: "dark", tokens: { colors: { /* ... */ - border: color, input: color, ring: color, + border: color, input: color, ring: color, selection: color, }, /* ... */ }}); ``` `ColorTokens::default()` was every field zeroed, which is transparent on transparent. It is now `ColorTokens::light()`, so a Base application that never installs a palette renders legibly instead of black on black. This also removes the `gpui-shell` binary's shipped palette and the "can this palette tell ink from paper" guard in `failure_surface`, both of which existed only to work around the zeroed default. ```diff - let tokens = ColorTokens::default(); // all zeroes + let tokens = ColorTokens::default(); // == ColorTokens::light() ``` A palette deserialized from JSON with `#[serde(default)]` fields now falls back to the light value for anything it omits, rather than to transparent. ## Test plan - `cargo test --workspace --exclude gpui-shell --features gpui-component-story/test-support` - `cargo test -p gpui-component --doc` - `cargo check -p gpui-component --no-default-features` - `cargo clippy -p gpui-component -p gpui-component-story -p gpui-component-assets -- --deny warnings` - `cargo machete` --- Parts of this PR were written with Claude Code. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 30 天前 | |
chore: Use gpui-kit (#2929) ## Summary Zed owns the `gpui` crate names on crates.io and publishes them only occasionally. This PR adds `script/bump-gpui.ts` (Bun) to publish a snapshot of any Zed commit to crates.io under our own names, a weekly `Release GPUI` workflow that runs it, and switches the workspace, README and docs to those crates. | Zed crate | Published as | | --- | --- | | `gpui` | `gpui-pre` | | `gpui_platform` | `gpui-pre-platform` | | `gpui_macros` | `gpui-pre-macros` | | `reqwest_client` | `gpui-pre-reqwest-client` | | `gpui_<x>` / other internal crates | `gpui-pre-<x>` | What the script does: - Fetches the requested Zed revision (`--rev`, default `main`) into `target/gpui-pre/zed`, or reuses a checkout passed with `--zed`. - Walks the workspace path dependencies of the four root crates and publishes the whole closure (25 crates today) at one version, `<VERSION>.<N>` (e.g. `0.3.12`): the `VERSION` constant at the top of the script (`0.3`) plus a patch number that continues from the highest one crates.io already has (`0.3.0` first). A run that stopped part-way resumes the same number. A positional argument publishes an explicit version instead. - Keeps each crate's original name as `[lib] name`, so consumers write `gpui = { package = "gpui-pre", version = "0.3.0" }` and `use gpui::*` unchanged; `actions!` and `#[derive(Action)]` keep working. - Drops optional dependencies that come from git without a crates.io version (`proptest`, `async-tar`) together with the features that enable them, then removes optional dependencies nothing can enable any more. This keeps Zed's `util` crate (which needs Zed's git-patched `async-process`) out of the publish set. - Swaps the workspace `reqwest` dependency (Zed's git fork) for the hand-published `gpui-pre-reqwest` through `DEPENDENCY_OVERRIDES`. - Vendors the gpui source files that `gpui_apple`'s build script reads from `../gpui`, since a crate unpacked from crates.io has no such sibling. - Verifies everything with `cargo publish --workspace --dry-run`, then publishes with `cargo publish --workspace`, re-checking crates.io before each attempt and waiting out the new-crate rate limit so a run can be resumed. Workflow: - `.github/workflows/release-gpui.yml` runs the script every other Sunday (even ISO weeks, gated by a small `cadence` job since cron cannot express two weeks) at 18:00 Beijing time (`0 10 * * 0` UTC) and on `workflow_dispatch` with optional `rev` and `version` inputs, on `macos-latest` so `gpui_apple`'s Metal shader build script is verified. It uses the `CARGO_REGISTRY_TOKEN` secret and writes the published crate table to the job summary. Workspace and docs: - `Cargo.toml` now depends on `gpui-pre` 0.3.0 (`gpui`, `gpui_platform`, `gpui_web`, `gpui_macros`, `reqwest_client`, `sum-tree`) and `gpui-pre-reqwest` 0.12.15 instead of the Zed git repository, `zed-sum-tree` and Zed's reqwest fork. The `[profile.dev.package]` overrides follow the new package names. - README (en/zh-CN), the site docs (en/zh-CN), the gpui-component skill, and the crate READMEs show the `gpui-pre` dependency lines. - CONTRIBUTING documents the workflow and version scheme. ## gpui-kit `crates/kit` (published as `gpui-kit`, names already reserved on crates.io) is the one crate applications depend on. It pins the matching `gpui-pre-*` set and re-exports every layer: | Path | Crate | Feature | | --- | --- | --- | | `gpui_kit::gpui` | `gpui` | always | | `gpui_kit::platform` | `gpui_platform` | always | | `gpui_kit::base` | `gpui-base` | always | | `gpui_kit::component` | `gpui-component` | `component` (default) | | `gpui_kit::assets` | `gpui-kit-assets` | `assets` (default) | | `gpui_kit::shell` | `gpui-shell` | `shell` (default) | | `gpui_kit::webview` | `gpui-wry` | `webview` | `gpui_kit::application()` and `gpui_kit::init()` cover startup, and `gpui_kit::prelude::*` also brings the crate names into scope, so `gpui::…` paths and the `actions!` / `#[derive(Action)]` macros (which expand to `gpui::…`) work without a direct `gpui` dependency. The `gpui-component` features (`inspector`, `decimal`, `tree-sitter*`) are forwarded by name. README, the site docs, the skill, the crate READMEs and `hello_world` now show `gpui-kit = "0.6"` alone; the docs no longer link GPUI to gpui.rs. Workspace crates are bumped to 0.6.0. ## Breaking Changes `gpui-component-assets` is renamed `gpui-kit-assets`; the `links` key is unchanged so `gpui-component`'s build script still finds the icon directory. ```diff -gpui-component-assets = "0.5" +gpui-kit-assets = "0.6" ``` ```diff -use gpui_component_assets::Assets; +use gpui_kit_assets::Assets; ``` Applications that listed GPUI themselves can drop those lines: ```diff -gpui = { package = "gpui-pre", version = "0.3.0" } -gpui_platform = { package = "gpui-pre-platform", version = "0.3.0", features = ["font-kit"] } -gpui-component = "0.5" +gpui-kit = "0.6" ``` ## Release gate Before anything is uploaded, `script/bump-gpui.ts` builds and tests this repository against the staged crates (mirrored outside the checkout and injected with `--config patch.crates-io…`; `Cargo.lock` is scratch-updated and restored, and `cargo metadata` proves the patch resolved). CI's `check`, `clippy` and `test` must pass, so a Zed change that no longer fits `gpui-component` fails the release instead of reaching applications through their caret `gpui-pre` requirement on `cargo update`. `--skip-kit-check` bypasses it. The workflow installs the system dependencies for that step. The facade-aware macro rewrite now copies `#[cfg]` gates onto the wrapped bodies (the published 0.3.1 `gpui-pre-macros` breaks release builds without `inspector`; 0.3.2 fixes it) and the `actions!` rewrite is scoped to the `macro_rules!` block. `gpui-shell` is not published for now (its `llrt_*` dependencies are git-only) and is no longer part of `gpui-kit`; `gpui-fps` is. `release.yml` publishes our crates with one ordered `cargo publish -p …`. ## Verification - `./script/bump-gpui.ts --dry-run --zed <local zed checkout>`: all 25 crates package and build; `gpui-pre-reqwest` resolves from crates.io. - With a temporary `[patch.crates-io]` pointing at the staged workspace (not committed), `cargo check --workspace` passes for every crate, story, story-web and example. - A scratch consumer crate depending on the staged crates via `package = "gpui-pre"` passes `cargo check`, including `actions!`, `#[derive(Action)]` and `collections::` by its original lib name. - `gpui-kit`: `cargo check` with default, no, `base`-only, `component`-only and `webview,inspector,tree-sitter-rust` features, its doc tests, `cargo check --workspace`, the CI clippy set plus `gpui-kit` and `hello_world` with `--deny warnings`, and `cargo machete` all pass against the staged `gpui-pre`. - `tsc --strict` with `@types/bun`, `typos`, and a YAML parse of the workflow pass. `gpui-pre` 0.3.0 is not on crates.io yet, so CI cannot resolve dependencies until the `Release GPUI` workflow has run (by hand, or on the next even ISO week Sunday). A requirement of `0.3.0` accepts every later `0.3.x` as well. `Cargo.lock` is left for that first resolution. ## AI assistance The script, workflow, dependency switch and documentation were written with Claude Code and reviewed by hand. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01D2PVGzukYKuXnb3LB5s53T --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> | 27 天前 |