feat(editors): add Registry Stack YAML navigation previews#409
Conversation
ebdb7db to
d3c5f42
Compare
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
d3c5f42 to
a710c85
Compare
jeremi
changed the title
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a710c85d28
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| SymbolKey::scoped( | ||
| RegistrySymbolKind::Claim, | ||
| &service_name, | ||
| &claim.key.value, |
There was a problem hiding this comment.
When two different services define the same claim ID, registryctl check rejects the project because project_authoring/project.rs keeps a single project_claim_ids set and bails with “Notary claim ids must be unique across project services.” The new LSP keys claim symbols by service_name, so build_diagnostics() only reports duplicates within the same service; editors will show no duplicate diagnostic for a project that the CLI refuses. Use a project-global claim key for duplicate detection, or add a separate global duplicate pass while keeping service-scoped navigation where needed.
Useful? React with 👍 / 👎.
| if let Some(output) = claim.value.get_scalar("output") { | ||
| if let Some((consultation, _)) = output.value.split_once('.') { |
There was a problem hiding this comment.
This only records consultation references for claims that use output, but registry-backed claims can also use cel expressions rooted at consultations; for example the bundled HTTP starter has cel: person_record.matched, and inferred_claim_evidence() treats consultation roots in CEL as registry-backed evidence. In those projects, renaming or misspelling the consultation inside cel produces no Registry Stack definition/reference support or missing-reference diagnostic, even though it is the same cross-reference the preview is meant to cover.
Useful? React with 👍 / 👎.
| case "${path}" in | ||
| editors/*) | ||
| editors=true | ||
| ;; |
There was a problem hiding this comment.
The new editor job is gated only by editors/*, but the VS Code and Zed previews both launch crates/registry-language-server and the job’s own test section builds that crate before exercising the extensions. A PR that changes only crates/registry-language-server sets the existing rust flag via crates/* but leaves editors=false, so the extension-host and Zed integration checks are skipped for the shared protocol/server they depend on.
Useful? React with 👍 / 👎.
| if let Some((path, id)) = external_id { | ||
| claimed_definition_files.insert(path.clone()); | ||
| self.add_resolvable_symbol(key, None, path, id.range); |
There was a problem hiding this comment.
For entity aliases, registryctl rejects the project unless the manifest key points to entities/<alias>.yaml and the referenced document's id equals that alias. This branch accepts any parsed entity file with a scalar id and registers it under the manifest alias, so an editor shows clean references for projects that registryctl check refuses, such as entities: resident: { file: entities/person.yaml } or an id mismatch inside the entity file.
Useful? React with 👍 / 👎.
| let supported = match kind { | ||
| RegistrySymbolKind::Integration => is_integration_path(path), | ||
| RegistrySymbolKind::Entity => is_entity_path(path), |
There was a problem hiding this comment.
For integration aliases whose file is a valid relative authored path outside integrations/*/integration.yaml, registryctl only validates the relative path and then loads that file, but the LSP rejects it here by requiring is_integration_path(). Those CLI-valid projects get a false “outside the supported project layout” diagnostic plus unknown integration references in the editor; either enforce the same layout in project validation or have the LSP securely load the declared integration path.
Useful? React with 👍 / 👎.
1 participant
Summary
registryctl authoring language-serverBeta support boundary
The generated editor setup from
registryctl initandregistryctl authoring editorremains the stable beta path.VS Code and Zed semantic navigation are optional developer previews for this beta. They must be built and installed from the source checkout. They are not marketplace extensions or release assets.
VS Code uses an explicit configured server, then
registry-language-serveronPATH, thenregistryctl authoring language-server. It is disabled in untrusted and virtual workspaces. Zed uses the same PATH/fallback order; because its current extension API cannot predicate YAML registration onregistry-stack.yaml, the docs tell users to remove the development extension after previewing to avoid unrelated-worktree noise.Review repairs
node_modulesdependencyVerification
Exact head:
a710c85d283a5298c0384940f5a40d92c6656c17Exact base:
6fe963e36ba15c320f6b3de0f98e4326473d27cecargo fmt --all -- --checkcargo check --locked --workspace --all-targetscargo clippy --locked --workspace --all-targets -- -D warningscargo test --locked -p registry-language-server(14 unit, 4 protocol)cargo test --locked -p registryctl --test language_servernpm run package:devand Extension Host testswasm32-wasip2check/test-no-run/formatnpm testand fullnpm run checkMerge gate
Every applicable exact-head GitHub check passed before merge.