Prefixing sourcekit/ to LSP/BSP Extension Methods
We are planning a naming change for SourceKit-LSP-specific LSP/BSP extensions.
All extension method names will be prefixed with sourcekit/ (e.g. textDocument/tests → sourcekit/textDocument/tests).
Motivation
This change is intended to avoid potential conflicts with future LSP/BSP standard methods. As the protocols evolve, unprefixed extension names may collide with standardized ones, so introducing a prefix provides a clear namespace for SourceKit-specific functionality.
Relevant PRs
- https://github.com/swiftlang/sourcekit-lsp/pull/2632
- https://github.com/swiftlang/swift-tools-protocols/pull/48
Impact on swift-tools-protocols API
This change only affects the method names on the wire. The Swift type names in swift-tools-protocols will not change. So most library users should be able to adopt this change without any source changes, aside from updating to a version that includes the new method names.
Migration Plan
SourceKit-LSP
- Accept incoming requests/notifications using both old and new names
- Send outgoing messages using the new names, falling back to the old names if the new ones result in
methodNotFound - Accept experimental LSP client capabilities under both naming schemes
- Advertise experimental LSP server capabilities under both naming schemes
- Start advertising experimental BSP client capabilities for incoming messages under both naming schemes
Editors (e.g. VS Code extensions)
- Should advertise client capabilities using both naming schemes
- Should determine which method names to use based on the server’s advertised capabilities
- Should accept incoming requests/notifications using both naming schemes
Build Servers (e.g. SwiftPM)
swift-tools-protocolsusers- Should adopt the updated
swift-tools-protocolsas soon as possible - Until then (given the limited benefit of dual support on this path):
- Should accept client-to-server messages using the old names
- Should send server-to-client messages using the old names
- Should adopt the updated
- Others
- Should advertise server capabilities using both naming schemes
- Should determine which method names to use based on the sourcekit-lsp advertised capabilities
- Should accept incoming requests/notifications using both naming schemes
Deprecation Plan
- Old (unprefixed) method names will be considered deprecated immediately after this change
- Support for old names in
sourcekit-lspwill be removed one year after the Swift 6.4 release
Affected Methods (for reference)
For completeness, the following extension methods are affected by this change.
LSP (peer: editor)
Incoming (Editor → SourceKit-LSP) Requests
textDocument/doccDocumentation→sourcekit/textDocument/doccDocumentationtextDocument/tests→sourcekit/textDocument/testsworkspace/getReferenceDocument→sourcekit/workspace/getReferenceDocumentsourceKit/_isIndexing→sourcekit/isIndexingworkspace/_outputPaths→sourcekit/workspace/outputPathsworkspace/_setOptions→sourcekit/workspace/setOptionsworkspace/_sourceKitOptions→sourcekit/workspace/sourceKitOptionsworkspace/synchronize→sourcekit/workspace/synchronizeworkspace/triggerReindex→sourcekit/workspace/triggerReindexworkspace/playgrounds→sourcekit/workspace/playgroundsworkspace/tests→sourcekit/workspace/tests
Incoming (Editor → SourceKit-LSP) Notifications
window/didChangeActiveDocument→sourcekit/window/didChangeActiveDocument
Outgoing (SourceKit-LSP → Editor) Requests
workspace/peekDocuments→sourcekit/workspace/peekDocumentsworkspace/playgrounds/refresh→sourcekit/workspace/playgrounds/refreshworkspace/tests/refresh→sourcekit/workspace/tests/refresh
BSP (peer: build server)
Incoming (Build Server → SourceKit-LSP) Notifications
build/sourceKitOptionsChanged→sourcekit/build/sourceKitOptionsChanged
Outgoing (SourceKit-LSP → Build Server) Requests
buildTarget/prepare→sourcekit/buildTarget/preparetextDocument/sourceKitOptions→sourcekit/textDocument/sourceKitOptionsworkspace/waitForBuildSystemUpdates→sourcekit/workspace/waitForBuildSystemUpdates
Feedback Requested
- Does this migration plan seem reasonable for editors and build servers?
- Is the timeline sufficient for downstream adoption?
- Any concerns around capability negotiation or fallback behavior?