fix(ios): use version range instead of deleted 8.0.0 branch for capacitor-swift-pm

[kstruempf]

Fixes #697

The problem

Package.swift declared the Capacitor dependency with a branch requirement:

.package(url: "https://github.com/ionic-team/capacitor-swift-pm.git", branch: "8.0.0"),

Two consequences, as reported in #697:

1. A branch requirement overrides every version requirement elsewhere in the dependency graph. An app asking for @capacitor/ios 8.5.0 still silently resolved Capacitor to 8.0.0, losing access to newer APIs such as the UIScene adoption Xcode 27 requires.
2. refs/heads/8.0.0 no longer exists upstream, so fresh package resolution fails outright. Only checkouts with an existing Package.resolved kept building.

The fix

.package(url: "https://github.com/ionic-team/capacitor-swift-pm.git", from: "8.0.0"),

from: means >= 8.0.0, < 9.0.0 — the same major-version floor the plugin already assumed, and the approach the first-party Capacitor plugins use. The 8.0.0 tag still exists upstream, so the floor is genuinely unchanged.

Verified: swift package resolve with no Package.resolved present now succeeds and picks capacitor-swift-pm 8.5.0.

Second commit: npm audit

Separate commit, happy to drop it if you would rather keep this PR to the one-line fix.

npm audit reported 13 advisories (1 critical, 6 high, 6 moderate), all reachable only through devDependencies — the published package's runtime dependency set was never affected, so no consumer was exposed. Cleared with plain npm audit fix (no --force, no package.json range changes), leaving 0 vulnerabilities. Notable ones: node-tar (critical, file smuggling via PAX header handling) through @capacitor/cli, js-yaml and brace-expansion DoS through eslint, lodash prototype pollution through java-parser, @xmldom/xmldom XML injection through plist.

One side effect worth flagging: the lockfile moves prettier-plugin-java 2.8.1 → 2.10.3, and the newer formatter drops redundant parentheses. That is why 6 Java files show up in the diff — 16 lines, purely return (State.UNKNOWN); → return State.UNKNOWN; style changes, no semantic difference. Applied so npm run lint stays green. Confirmed this churn is caused by the bump and is not pre-existing (master formats clean under 2.8.1).

Verification

• swift package resolve — resolves capacitor-swift-pm 8.5.0
• npm audit — 0 vulnerabilities
• npm run build, npm run build-electron — pass
• npm run lint — eslint, prettier, swiftlint all pass (0 serious; the swiftlint warnings are pre-existing)
• cd android && ./gradlew clean build test — passes

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The lockfile update introduces stricter Node engine requirements in the resolved dependency tree that conflict with the repo’s declared Node support policy and should be reconciled to avoid contributor install breakage.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

This PR fixes Swift Package Manager dependency resolution for the iOS package by switching the Capacitor SPM dependency from a deleted branch pin to a semantic version range, and also updates the npm lockfile via npm audit fix to clear devDependency advisories.

Changes:

• Update Package.swift to depend on capacitor-swift-pm via from: "8.0.0" instead of branch: "8.0.0".
• Apply npm audit fix changes to package-lock.json.
• Accept formatter-driven Java parenthesis cleanups in a few Android sources (no intended behavioral changes).

File summaries

File	Description
Package.swift	Replaces deleted branch pin with a version-range dependency for Capacitor’s SPM package.
package-lock.json	Updates resolved devDependency graph to address npm audit advisories.
android/src/main/java/com/getcapacitor/community/database/sqlite/SQLite/UtilsSQLite.java	Formatter-only parentheses simplification in byte conversion loop.
android/src/main/java/com/getcapacitor/community/database/sqlite/SQLite/UtilsSQLCipher.java	Formatter-only parentheses removal in enum returns.
android/src/main/java/com/getcapacitor/community/database/sqlite/SQLite/UtilsMigrate.java	Formatter-only parentheses removal around method arguments.
android/src/main/java/com/getcapacitor/community/database/sqlite/SQLite/UtilsFile.java	Formatter-only parentheses removal around method argument.
android/src/main/java/com/getcapacitor/community/database/sqlite/SQLite/ImportExportJson/JsonIndex.java	Formatter-only parentheses simplification in type check/compare.
android/src/main/java/com/getcapacitor/community/database/sqlite/CapacitorSQLitePlugin.java	Formatter-only boolean expression simplification.

Review details

• Files reviewed: 7/8 changed files
• Comments generated: 0
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[kstruempf]

I don't think the lockfile is the source of this. I diffed every engines.node constraint between master and this
branch - the effective Node floor is 20 on both sides, unchanged.

master already requires Node 20 via rimraf@^6 → glob/lru-cache/path-scurry, all declaring 20 || >=22. The
only tightening here is brace-expansion nested under glob (18 || 20 || >=22 → 20 || >=22), which was already
unreachable below Node 20 because its parent demands 20 anyway.

So the mismatch with engines: ">=16.0.0" predates this PR. Also: no engine-strict in .npmrc, so mismatches are
EBADENGINE warnings, not install failures. And >=16 is arguably right as a consumer declaration - the only Node
constraint in the production tree is @stencil/core >=16.0.0; the Node 20 floor is entirely in devDependencies, which
consumers never install.

---

There is a real gap underneath, though: the toolchain needs Node 20+ but nothing says so - engines says >=16, CI
pins 22, no .nvmrc. Happy to open a separate PR adding .nvmrc and aligning CI on the current Active LTS (Node 24).
That documents what's already true with zero consumer impact. Bumping consumer-facing engines is a support-policy call I'd leave to you. Neither blocks this PR.