Skip to content
Beskid Platform specification

Beskid

Jump to a Beskid service

Beskid

Jump to a Beskid service

Flow and algorithm

Platform spec article

Flow and algorithm

Spec standingStandard

Owner
Piotr Mikstacki
Submitter
Piotr Mikstacki

Operational sequences for registry browse and project mutation from the Packages view.

  1. Read focusedProjectUri from workspace state.
  2. If set, executeCommand('beskid.getProjectDependencies', { projectUri }).
  3. Replace ThisProject children; preserve RegistrySearch expansion state.
  4. Re-resolve registry base URL from workspace summary when workspace membership changes.
  1. User invokes beskid.packages.search or view-title Search.
  2. Show InputBox for query q.
  3. Debounce 300ms; set status phase search.
  4. searchPackages({ q, registryBaseUrl }) via cache.
  5. Populate RegistrySearch with searchResult nodes (package name + health summary).
  6. Clear status phase on completion or error.
  1. User expands a searchResult node.
  2. If details not cached, set phase details, call getPackageDetails({ name }).
  3. Attach version child nodes sorted by semver descending.
  4. Expanding a version loads registryDependency leaves from dependencies[] in details response (no extra HTTP unless stale).
  1. User chooses Fetch or Lock from view title (requires focus).
  2. CLI runner spawns beskid with cwd = directory containing focused Project.proj.
  3. Stream output to Beskid LSP output channel; status phase fetch or lock.
  4. On exit code 0: beskid.packages.refresh + beskid.refreshWorkspace + tree providers update.
  5. On non-zero: error notification with last stderr lines.
  1. Prompt package name and version (quick pick optional for known search result).
  2. If CLI exposes beskid add (or equivalent), invoke via runner.
  3. Else insert dependency stanza into Project.proj at canonical location; save; trigger LSP refresh.
  4. User should run Lock after add when lockfile policy requires it.