fix: remove SPM testTarget escaping the package root (strict SwiftPM toolchains reject the manifest)#54
Merged
vietnguyentuan2019 merged 4 commits intoJul 17, 2026
Conversation
The manifest declared NativeWorkManagerTests with path: "../Tests", which escapes the package root (ios/native_workmanager/). Some SwiftPM toolchains reject the ENTIRE manifest at load time with "target 'NativeWorkManagerTests' in package 'native_workmanager' is outside the package root" — killing dependency resolution for every SPM-enabled consumer on those toolchains. Newer SwiftPM (Xcode 26.x) tolerates the escape, which is exactly why local verification passed while CI's 'Build Validation (iOS)' job failed on main. Nothing ever ran that test target (no workflow or script invokes swift test), so removing it loses no coverage — the Swift tests in ios/Tests/ stay in the repo for future wiring via the example workspace or a dev-only manifest. Consumer-facing plugin manifests should not declare test targets at all (cf. firebase plugins). Verified: swift package dump-package (3 targets, hyphenated product, no test target), hyphenated-product consumer resolves, scratch Flutter app with SPM enabled builds to ✓ Runner.app. The previously red CI job is the controlled experiment for the old-toolchain side.
Full local gate before this commit: flutter analyze 0 issues, dart format 0 changed, 1898 unit tests pass, pana 160/160 on both packages.
…ript-injection vector
The 'Validate PR' job inlined ${{ github.event.pull_request.title }} and
.body directly into bash. Any quote or paren in a PR description broke the
script (this PR's own body did: 'syntax error near unexpected token ('), and
worse, $(…) in a title or body from any fork PR would EXECUTE on the runner.
Both now flow through env vars and are only ever expanded by the shell as
data, per GitHub's hardening guidance.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by the red
Build Validation (iOS)job on main (red since May, so it never gated a PR):flutter build ioson an SPM-enabled toolchain fails dependency resolution withRoot cause
Package.swiftdeclared a.testTargetwithpath: "../Tests"— outside the package root (ios/native_workmanager/). Stricter SwiftPM toolchains reject the whole manifest at load time; newer ones (Xcode 26.x) tolerate it. That split is exactly why every local verification passed while this CI job failed — and it means SPM-enabled consumers on the stricter toolchains can't resolve the package at all, same failure mode as #49/#52.Fix
Drop the test target from the consumer-facing manifest (nothing ever ran it — no workflow or script invokes
swift test; zero coverage lost).ios/Tests/stays in the repo. Consumer-facing plugin manifests shouldn't declare test targets, which is also what the big plugins do.Verification
swift package dump-package: hyphenated product, 3 targets, no test target✓ Built Runner.appBuild Validation (iOS)check — it reproduces the stricter-toolchain failure on main and must go green here.