'No such module' for internal target import

Related Projects VSCode Swift extension
1

MacOS, VS Code + Sift extension, latest XCode, (Swift 6.2)

Have a project with a target, and an executable that uses that target
The apps are simple command-line apps, for Mac

import MyTarget is not recognized, all other, like ArgumenetParser, are
Jump to definition does therefore not work

Already re-indexed, removed build folder, selected a build target, … nothing fixes these issues

Any idea how to get VS Code working?
It used to work in the past …

2

Some more info: I tried to reproduce with a fresh hello world project, but that works and I can not share the project I have the problem with

but I think I found the reason, my lib uses this project, for which I can share the source since its an open source project :slight_smile:

and when I open this project, it has an issue finding it’s internal lib, Libsql

Screenshot 2026-01-02 at 13.40.30
Screenshot 2026-01-02 at 13.40.302104×1386 421 KB

and when I refactor my project so everything that uses Libsql is in its own library, than only this one has SourceKit problems, not my other library with the rest of the code

So something seems to be in Libsql-swift from the Turso project that confuses SourceKit
And I would like to know what, so I can help to make this project just work :slight_smile:

3

I would raise an issue against the SourceKit-LSP repository including your sample project that exhibits the problem. You can also run sourcekit-lsp diagnose in your terminal to generate a diagnostics bundle that can be included in the issue.

4

I actually found the reason. The project has a xcframework, with static libs, and swift build finds them, but SourceKit not.
I noticed that when I ported the build to Linux, and the IDE was working on Linux (except for the sPM plugin part, but that is a different topic)
So that brought me the rigth idea for a fix

In anycase, I documented the problem and ‘solution’ (workaround) here

not sure if I need / shall report that to anyone other than here, thought this is the place :slight_smile:

5

Thanks for noticing and reporting this, @a4z. Could you file an issue for this in GitHub - swiftlang/sourcekit-lsp: Language Server Protocol implementation for Swift and C-based languages, so we can track the issue?

As a workaround, you could try setting "backgroundPreparationMode": "build" in your .sourcekit-lsp/config.json file (sourcekit-lsp/Documentation/Configuration File.md at main · swiftlang/sourcekit-lsp · GitHub), though there are other issues with that like reduced performance and reduced semantic functionality if one of your dependent targets doesn’t build successfully.

6

I just noticed this post and I'm recently working on some C++ interop stuff so I'm also having this issue.

It's easily reproducible by cloning GitHub - MahdiBM/simdutf-swift-example: An example of using `simdutf` in Swift via Swift's C++ interop and safe `Span` types. which is a very small project of a few files.
I consistently get Could not build Objective-C module 'simdutf' - SourceKit on Cursor while the build does actually work and the mini app runs fine.
The autocompletes also works rarely for simdutf but do work for other stuff.
I'm using the latest 6.3 nightly on macOS 26.2, since it contains some big fixes.

I thought I mention this while passing by. I can file an issue or post a message about this in an existing issue as well (e.g. if @a4z creates one).

7

Ok maybe I was passing by way too fast that I didn't notice these are not exactly the same issue?

Or maybe they are related but still not exactly the same.

This post reminded me of my own issue so I kind of assumed they must be the same, for no reason.

8

I created the issue, hope it helps to improve the developer experience

1 Like
9

setting this in the .sourcekit-lsp/config.json does also work

Does that have any disadvantages?

10

Yes. Before you can work on a source file, we need to prepare its target (this is the action that’s failing). We usually skip a bunch of work to make preparation as fast as possible and continue on errors. With "backgroundPreparationMode": "build", we perform an entire build of the target to prepare it, which (a) takes longer and (b) will fail if one of the dependencies fails to build, so you will get regressed editor functionality if one of your target’s dependencies fails to build.

1 Like