[X-Guardian]

Summary

• Version completion after @ showed nothing when a YAML extension's word pattern treats /, $ and @ as word characters (the Red Hat YAML extension's does). The items had no range, so VS Code filtered them against the word at the cursor, which was the whole $CI_SERVER_FQDN/group/project/component@ reference. No version label matched it.
• Each version item now replaces only the text after @. parseVersionCompletionPrefix reports where that slot starts, and the provider sets the item's range from there to the cursor, so VS Code filters on the partial version alone.
• Link related issue(s): Closes bug: completion: no version suggestions after @ when the YAML extension's word pattern is active #378

Change Type

• feat
• fix
• refactor
• docs
• test
• chore

Context

User-facing impact

• Versions appear after @ again. With or without the Red Hat YAML extension, typing @ after a cached component lists its versions, and typing part of a version narrows the list.
• Accepting an item behaves the same. The inserted text is unchanged; only the replaced span is now explicit.

Why a range rather than filterText

Setting filterText to the version would still be scored against the whole-reference word, since VS Code takes the word from the item's range (or, absent one, the word at the cursor). The range is the thing that was wrong, so the fix sets it. The slot column comes from the parser the provider already uses, which keeps the regex as the one place that knows where the version starts.

GitLab scope

• gitlab.com
• self-managed GitLab
• both

Affected areas

• Component Browser
• Hover provider
• Completion provider
• Validation provider
• Cache and refresh behavior
• GitLab API calls/auth/token storage
• Docs only

What changed by bucket

Bucket	Files	Approach
Parser	src/utils/componentReference.ts	parseVersionCompletionPrefix also returns versionStart, the column right after the @.
Provider	src/providers/completionProvider.ts	provideVersionCompletions takes the cursor position and sets every version item's range to [versionStart, cursor] on that line.
Tests	tests/unit/componentReference.test.ts	See below.

Validation

Local checks

• npm run compile
• npm test (876 passing)
• npm run lint (clean, --max-warnings 0)
• npm run test:extension-host
• Manual verification in VS Code Extension Host with the Red Hat YAML extension enabled

Tests

• componentReference.test.ts: every parseVersionCompletionPrefix case asserts versionStart, including the empty partial version, the quoted reference, references with $CI_SERVER_FQDN and ${CI_SERVER_FQDN}, and a new case where the partial version itself contains a / (@feature/my-).
• No extension-host test: the host suite runs with --disable-extensions and no network, so it can neither install the YAML extension's word pattern nor seed a cached remote component. The parser test pins the column; the range assignment is one line.

Breaking Changes

• No breaking changes
• Breaking changes (describe below)

parseVersionCompletionPrefix returns an extra field. Its only callers are the completion provider and its tests.

Screenshots / Recordings (if UI behavior changed)

• Before: with the Red Hat YAML extension enabled, - component: $CI_SERVER_FQDN/g/p/c@ shows no suggestions.
• After: the same line lists the component's versions.

Risk and Rollback

• Main risks:
  1. The range is built from the line prefix, so it always ends at the cursor. Text after the cursor on the same line is left alone, as before.
  2. If a future word pattern made @ part of the word in the other direction (so the word started inside the version), the explicit range still wins, since VS Code uses the item's range when one is set.
• Rollback strategy: revert the commit. No persisted state changes.

Release Notes Draft

• Version suggestions after @ in a component: reference now appear when the Red Hat YAML extension (or any YAML word pattern that allows / and @ in a word) is active.

Checklist

• Branch is up to date with target branch
• Commit messages follow conventional commits
• Added/updated docs for behavior or settings changes (none needed)
• Added/updated tests for new behavior
• No secrets or tokens in code, logs, screenshots, or test fixtures