plugin: add Swift language tooling workflows#153
Conversation
Why: Give agents explicit syntax, compiler, semantic-index, and LSP paths while preserving Swiftly and Xcode toolchain ownership. Verification: Validated all five skill folders with the skill-creator validator.
Why: Publish the Swift language-tooling expansion across Socket's Codex, Claude, Cowork, and Hermes surfaces and reserve the API-analysis second wave in the roadmap. Verification: - five skill-creator validations - 102 pytest tests passed; 1 skipped - Ruff passed - mypy passed - Socket metadata, Hermes, and Claude compatibility validators passed
|
Important Review skippedToo many files! This PR contains 135 files, which is 35 over the limit of 100. To get a review, narrow the scope: Upgrade to a paid plan to raise the limit. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (8)
📒 Files selected for processing (135)
You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d41d5a4b61
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| commands = ["swift package plugin --list", "swift package init --type build-tool-plugin"] | ||
| elif extension_type == "command-plugin": | ||
| commands = ["swift package plugin --list", "swift package plugin --help", "swift package init --type command-plugin"] | ||
| elif extension_type == "macro": | ||
| commands = ["swift package init --type macro", "swift build", "swift test"] |
There was a problem hiding this comment.
Replace package init commands for existing packages
For plugin and macro requests this workflow only reaches success after Package.swift is present, but these planned commands initialize a new package template. I checked Swift 6.2.4: swift package init --help describes initializing a new package, and running it in a package reports a manifest file already exists, so users following a successful existing-package plan will hit a dead command instead of adding plugin or macro targets. Gate these template commands to an empty bootstrap path or plan the manifest/target edits needed for the existing package.
Useful? React with 👍 / 👎.
| commands = ["swift package init --type macro", "swift build", "swift test"] | ||
| elif extension_type == "traits": | ||
| commands = [ | ||
| "swift package show-traits --format json", |
There was a problem hiding this comment.
Use a real SwiftPM trait inspection command
For trait requests the first planned command is not supported by the SwiftPM floor this workflow advertises. I checked Swift 6.2.4: swift package --help lists trait options such as --traits, --enable-all-traits, and --disable-default-traits, but no show-traits subcommand, and invoking swift package show-traits --help in a package errors with Unknown subcommand or plugin name. Users following the trait inventory path will fail before the build/test matrix, so this should use a supported inspection path.
Useful? React with 👍 / 👎.
Summary
Verification