feat(swift): switch pack.swift to xcodebuild.nvim and ditch xbase altogether

[gacallea]

Swift Lang Pack support and changes

Regarding { import = "astrocommunity.pack.swift" }, and official Swift Lang support.

Given

• XBase lackluster status and lack of funciontalities.
• xcodebuild.nvim is featureful, community praised, made by a veteran Swift developer with plenty of XCode knowledge.

I suggest

• we should ditch xbase altogether in favor of xcodebuild and only support the latter going forward.

Notes

I've opened a line of communication with @wojciech-kulik to implement some changes to peruse more native tooling. He likes my advice so far. I plan to contribute more. As I implement these pack.swift changes, I will keep the line open as I go.

@wojciech-kulik provides an example starter for nvim and I'm going to integrate as much as possible here, striking a balance to what the original tool suggests and leveraging AstroNvim native tools (or configurations).

Swift support

In the meantime the following will suffice to use sourcekit-lsp, swiftlint, and swiftformat (or swift_format) as a temporary measure.

-- user.init.lua
lsp = {
[...]
    servers = {
      "sourcekit",
    },
    config = {
      sourcekit = {
        cmd = { "sourcekit-lsp" },
        filetypes = { "swift", "objective-c", "objective-cpp" },
        -- root_dir = function() return require("lspconfig.util").root_pattern("Package.swift", ".git") end,
      },
    },
[...]
  },

-- user.null-ls.lua
[...]
    config.sources = {
      -- Set a formatter
      null_ls.builtins.formatting.swiftformat, -- https://github.com/nicklockwood/SwiftFormat
      -- null_ls.builtins.formatting.swift_format, -- https://github.com/apple/swift-format

      -- Set a linter
      null_ls.builtins.diagnostics.swiftlint,
    }
    return config -- return final config table
[...]

Conclusion

Any feedback appreciated, but I'm going to implement this anyway. The only doubt to clear would be if AstroCommunity needs two Swift packs or a good one only.

Cheers

[Uzaaft]

We should instead have a structure such that one has:

• Swift language pack
  And then move the plugin stuff to a seperate pack, something like programming-language-support makes sense.
  There, we'll have:
  xbase
  xcodebuild.nvim
  etc

[Uzaaft]

Any tools to handle xcode stuff should go in a seperate plugin, until it's more clear what is good or not. As it stands right now, my experience is that any xcode tools are at best very unstable/mixed bag of experience

[gacallea]

that is the thing: no swift tool is avaiable for autoinstall. source kit comes with Xcode. swiftlint and swift format (either one) is a manual (brew install) download.

basically all we could do would be treesitter. unless we give in on opinionated null-ls. see my OP swift support section.

[Uzaaft]

That's incorrect. Sourcekit comes with a toolchain, OR xode. It's available on both mac, linux and I THINK windows(provided by https://github.com/compnerd based upon what I've found on Apple's website).

Re the auto-instal issue, I think that's a non-issue tbh. Just as we're moving away from the rust pack auto-installing it, the same can be done with swift.

[gacallea]

damn i read this too late. didn't mean to ignore it. I just pushed a PR #670. Feel free to close/freeze it until we find a solution here.

[gacallea]

sure sourcekit-lsp is available for linux and windows, I knew this. Since we were talking XCode tools and support, I just restricted my field of vision to this. By autoinstall I meant: there is not mason support at all for any of these tools.

[gacallea]

moved XBase to plugin but the category fails because xcode is not an nvimcraft category. I tried my best. #671

pack.swift should be removed imho, unless #670 works as a solution (I know that opinionated is wrong, but here it seems necessary. else pack.swift to have treesitter only, doens't seem ideal. unless I'm missing something.