-
Notifications
You must be signed in to change notification settings - Fork 4
Codeface Documentation
You can always write at hello@codeface.io to get personal support.
Have a look at this showcase.
Install Codeface from the Mac App Store. Then download and open one of theses files.
To see dependency arrows and symbols, Codeface must talk to LSPService while importing a code folder. LSPService is a free open-source webservice that you can download and run on your machine. It can launch LSP servers and thereby provide Codeface detailed information about codebases of virtually all languages.
This tutorial describes how to setup and use LSPService.
Note that automatic Swift support only works for Swift packages, since Apple's LSP server does not support Xcode projects.
In following sections, you find more infos on support for Swift (Apple platforms), Dart (Flutter) and Kotlin (Android and KMP).
Have a look at this tutorial.
And indeed it is more cumbersome than we would have liked. Because of the App Store rules, it took a lot of work to make Codeface available in the App Store at all without losing its ability to leverage LSP servers. Another recent attempt to replace LSPService by an integrated XPC service also failed.
However, we're working on making LSP server integration easier on multiple fronts. For example, 1) LSPService will be signed, so its installation becomes smoother and 2) You'll be able to configure LSPService via a graphical interface from within Codeface. Because of these efforts, significant new features are currently all on hold.
When using an LSP server, importing larger codebases does indeed take long because requests to LSP servers can not generally be made in parallel.
You can accelerate loading a codebase visualization again by saving it to a .codebase file. Such a file stores a whole codebase, including all the data retrieved from an LSP server. Loading a codebase from file is much faster. So when you don't need to update the visualization, you can open it in Codeface without waiting for the LSP server.
If Xcode is installed, LSPService automatically finds Apple's LSP server (SourceKit-LSP), which supports Swift code. Using it with Swift code, you have to be aware of a few things:
-
SourceKit-LSP supports Swift Packages but not Xcode projects.
-
To update what SourceKit-LSP can "see", you have to
swift buildthe package from the terminal before importing it into a Codeface file. This is due to a caveat of SourceKit-LSP, which is still at an early stage. If the package contains a test target, you also need to build test, for instance viaswift test, to see the dependencies originating from the tests. -
Sometimes, deleting the hidden ".build" folder within the package before building it helps to update everything. You can show and hide hidden files on macOS via shift + ⌘ + . (Shift + Command + Dot).
The same LSP server from Apple should also work for Objective-c, C++ and C.
Codeface can import any code folder. But it can not open, import or otherwise know anything about Xcode projects. This is because Apple's LSP server does not support Xcode projects but only Swift packages.
We suspect that Apple's LSP server will never support Xcode projects but that instead the Swift Package Manager might some day support app targets and thereby more or less replace Xcode project files.
If your code is in an Xcode project, you can use a little "trick" to visualize it: Extract as much of it as possible into one or multiple local Swift packages. Many developers do that anyway to speed up compiles and to manifest/enforce architectural boundaries.
As described above, you have to swift build the package from the terminal before importing it into a .codebase file. This will update what Apple's LSP server can "see" during the import.
Sometimes, it's also necessary to delete the hidden ".build" folder inside the package folder before building the package. You can show and hide hidden files on macOS via shift + ⌘ + . (Shift + Command + Dot).
Dart includes an official Dart language server. When Dart is installed (possibly as part of Flutter), you should be able to launch its language server via dart language-server. It seems the client id and -version arguments are not required.
When adding an entry for Dart into the LSPServiceConfig.json file, you need to provide the full path to Dart. You can determine that path via the shell command which dart. The entry may then look something like this:
"dart" : {
"path" : "/Users/seb/Desktop/flutter/bin/dart",
"arguments" : [
"language-server"
],
"environment" : {}
}As with most languages, it is important to build a Dart-/Flutter project before importing it into Codeface.
Language Support For Kotlin (Android and KMP)
Install the Kotlin Language Server (KLS) via Homebrew: brew install kotlin-language-server
The default LSPServiceConfig.json file (generated by LSPService when the file doesn't exist) already contains the path of KLS, given that KLS was installed via Homebrew. The entry should look something like this:
"kotlin" : {
"path" : "/opt/homebrew/bin/kotlin-language-server",
"arguments" : [
],
"environment" : {
}
}As with most languages, it is important to build a Kotlin project before importing it into Codeface.
There are some Python LSP servers. One currently working is jedi-language-server. python-lsp-server and pyright are not working with the LSPService.
You can install jedi-language-server using pip: pip install jedi-language-server. Installing it inside a virtual environment does work too.
Add the following entry to the LSPServiceConfig.json file.
Find the path using which jedi-language-server (activate virtual environment before).
{
"python" : {
"path" : "/.../.env/bin/jedi-language-server",
"arguments" : [],
"environment" : {}
}
}
As with most languages, it is important to build a Python project before importing it into Codeface.