apple
Background indexing doesn't index packages in edit mode
Swift version
Apple Swift version 6.0.2 (swiftlang-6.0.2.1.2 clang-1600.0.26.4)
Platform
macOS 15
Editor
VS Code
Description
If I open a swift package and set one of its dependencies to be in edit mode the background indexing ignores this and still tries to index the project as if it is using the version of the dependency in .index-build.
Steps to Reproduce
- Open package with dependencies in VSCode
- Clone one of its dependencies in a separate folder
- Right click on dependency in package dependencies view, select "Use Local Version" and select your local clone of that dependency. This is the equivalent of running `swift package edit -path
- In main package right click on symbol from dependency and jump to definition
- Note you jump to version in
.index-buildand not the local version
This is most likely caused by the fact that the package edit commands edit the workspace-state.json file and these changes are not propagated to the .index-build folder.
Logging
No response
@ahoppen what are the chances this will get fixed for 6.1? This really breaks editing packages in VSCode
The fix for this would require a major architectural redesign of how SourceKit-LSP interacts with SwiftPM’s workspace state and integrates with SwiftPM’s build folder. It’s out-of-scope for 6.1.
Ok is there going to be a way to disable background indexing because editing packages just doesn't work with it.
Yes, you can disable it via the SourceKit-LSP Configuration file and there’s also a setting in VS Code.
Running into this as I work on SwiftPM with the swift-build dependency in edit mode.
Is this something that can be targeted for 6.2? I use package editing all the time and it is very frustrating.
+1 from me. I'm trying to codevelop SwiftPM/swift-build on Windows and the environment is tough without this. But I need to understand how sourcekit-lsp is getting its build info from SwiftPM to see how much of a change it is.
As far as I understand it there are two workspace-state.json files (one in .build and one in .build/index-build) and only one Package.resolved. You run swift package edit and the Package.resolved and workspace-state.json in .build are updated. Then sourcekit-lsp comes along and updates the Package.resolved with the information in its own workspace-state.json in .build/index-build thus reverting your swift package edit.
Ugh. This is definitely something I need for my swift build work on Windows/Linux. I'll grab some time over the next couple of days and dig into this a bit as well.
@dschaefer2 @ahoppen Is there any chance this will get resolved for Swift 6.2? It breaks all sorts of stuff having separate source trees for build and indexing.
I've been told it would be very complicated to fix. As much as we need it for working on SwiftPM and swift-build at the same time we haven't had the time to take a look.
@bnbarham As we work in the interface between sourcekit-lsp and swiftpm --build-system SwiftBuild, I wonder if this is something we could take into account?
I wonder if this is something we could take into account?
It might help, but it's unlikely to come for free. The main difference between this and a full IDE is that we don't know when package resolution/a build is happening, so we'll likely need to add something like a file lock during package resolution to protect checkouts + workspace state here. That doesn't seem too bad, but also isn't particularly related to the swift-build move.
so we'll likely need to add something like a file lock during package resolution to protect checkouts + workspace state here.
Doesn't SwiftPM already have this?
Doesn't SwiftPM already have this?
There's a lock through the commands, I don't remember if that's the case in the API we're using (I thought it wasn't, but maybe I'm wrong). But this will all move into SwiftPM with the swift-build move, which should make this much simpler to handle.