Extension takes longer to initialize on recent versions, Package.swift is resolved from parent folders

[rockbruno]

I noticed that after bumping from 2.0.2 to the newest 2.12.0 that the extension takes much longer to initialize than it used to, and I think it seems to have something to do with the Package.swift searching logic.

In this screenshot here the workspace doesn't have a Package.swift file, but still the extension parsed and provided info about a SPM project. This project is actually the parent folder, which is not included in the workspace. I believe this wasn't the case in the older builds and there doesn't seem to be an option to disable this behavior (you can disable looking into the child folders but apparently not the parents). This SPM project is opened on another Cursor window though, if that is a factor.

The project in question in https://github.com/spotify/sourcekit-bazel-bsp/tree/main/Example if you want to try it!

[award999]

@rockbruno if you reload VSCode do you get a notification on startup to generate or regenerate the debug launch configurations?

[plemarquand]

The extension doesn't search parent folders for workspace folders, and only searches in subfolders if the searchSubfoldersForPackages setting is enabled. You mentioned that the parent folder is already open in another window, could it be the two VS Code windows are sharing the same workspace?

In the next release folders with just a .bsp (such as the Example project linked) will activate the extension..

As for the slowdown, the most likely culprit is the "update debug configurations" dialog that blocked extension activation. If you're seeing that dialog, dismiss it and the extension should activate normally.

[rockbruno]

No notification on my end, it looks like the issue is something in SwiftPM itself because I can see from your end you're just running SwiftPM commands, and indeed if I run them in my Example app's folder it somehow starts building the content in the parent folder for some reason.