I finally got it working! Huge thanks to @mattmassicotte for helping me out!
This PR outsources the bundling of tree-sitter grammars to CodeEditLanguages. This hugely benefits package resolution times both in Xcode and in our CI.
What's different in CodeEditTextView?
Not much. The classes/structs TreeSitterModel & CodeLanguage now live in CodeEditLanguages. Apart from that the package works the same as before.
Background
Since we currently load each tree-sitter language as a SPM Package, and their repositories often are huge with a long git history, the resolution process for some packages takes a couple of minutes. Also all sources have to be built every time as well. Since those grammars usually don't change all that often, we can easily get away with putting them into a binary framework which eliminates both drawbacks of the current solution.
We only need to fetch the framework itself which is less than 30MB compared to ~1.4GB when fetching all the language packages on their own. Also all the C code in the language packages will be built already.
Technical Details
In CodeEditLanguages are both a SPM Package and a Xcode project. The project (CodeLanguages-Container) is only used for building a binary framework CodeLanguagesContainer.xcframework. The SPM Package CodeEditLanguages then embeds this binary and provides the classes/structs TreeSitterModel & CodeLanguage for the use in CodeEditTextView.
There are a few additional steps that need to be done when adding a new language:
Opening the Xcode project
Adding the tree-sitter dependency
Adding that module to the framework target
Adding a line in the header file
build the framework using a script
copying resources to the Package's resource folder using a script
I finally got it working! Huge thanks to @mattmassicotte for helping me out!
This PR outsources the bundling of
tree-sittergrammars toCodeEditLanguages. This hugely benefits package resolution times both in Xcode and in our CI.What's different in
CodeEditTextView?Not much. The classes/structs
TreeSitterModel&CodeLanguagenow live inCodeEditLanguages. Apart from that the package works the same as before.Background
Since we currently load each tree-sitter language as a SPM Package, and their repositories often are huge with a long git history, the resolution process for some packages takes a couple of minutes. Also all sources have to be built every time as well. Since those grammars usually don't change all that often, we can easily get away with putting them into a binary framework which eliminates both drawbacks of the current solution.
We only need to fetch the framework itself which is less than
30MBcompared to~1.4GBwhen fetching all the language packages on their own. Also all theCcode in the language packages will be built already.Technical Details
In
CodeEditLanguagesare both a SPM Package and a Xcode project. The project (CodeLanguages-Container) is only used for building a binary frameworkCodeLanguagesContainer.xcframework. The SPM PackageCodeEditLanguagesthen embeds this binary and provides the classes/structsTreeSitterModel&CodeLanguagefor the use inCodeEditTextView.There are a few additional steps that need to be done when adding a new language:
After that the usual steps apply.
Related Issue
54