Conversation
Reverts "chore: bump main to 9.0.0-dev.0 (ionic-team#8320)" and “chore: update latest workflow to only allow pointing at 8.x” This reverts commit c5476c8 and 0412d46
…8338) Co-authored-by: Mark Anderson <mark.anderson@outsystems.com>
Co-authored-by: Mark Anderson <mark.anderson@outsystems.com> Co-authored-by: Mark Anderson <emer@emer.net>
Co-authored-by: Stein Jakob Nordbø <steinjak@gmail.com> Co-authored-by: Pedro Bilro <pedro.gustavo.bilro@outsystems.com>
…onic-team#7528) Co-authored-by: Pedro Bilro <pedro.gustavo.bilro@outsystems.com> Co-authored-by: jcesarmobile <jcesarmobile@gmail.com>
Co-authored-by: Pedro Bilro <pedro.gustavo.bilro@outsystems.com>
Closes ionic-team#8367 Fixes regression introduced by ionic-team#8357
…onic-team#8391) Co-authored-by: Pedro Bilro <pedro.gustavo.bilro@outsystems.com>
…eam#8377) Co-authored-by: jcesarmobile <jcesarmobile@gmail.com>
…ic-team#8351) Co-authored-by: OS-pedrogustavobilro <pedro.gustavo.bilro@outsystems.com>
📝 WalkthroughWalkthroughThis pull request merges upstream Capacitor 8.3.0 into the Capacitor+ fork, involving package identity changes from Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aa22484a0b
ℹ️ 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".
|
|
||
| export async function generatePackageText(config: Config, plugins: Plugin[]): Promise<string> { | ||
| const iosPlatformVersion = await getCapacitorPackageVersion(config, config.ios.name); | ||
| <<<<<<< HEAD |
There was a problem hiding this comment.
This line is part of an unresolved merge block (<<<<<<< / ======= / >>>>>>>) inside generatePackageText, which leaves cli/src/util/spm.ts as invalid TypeScript and breaks CLI compilation/execution for commands that load this module (including iOS update/migration paths). Remove the conflict markers and keep a single valid implementation.
Useful? React with 👍 / 👎.
| "@ionic/eslint-config": "^0.4.0", | ||
| "@ionic/prettier-config": "^4.0.0", | ||
| "@ionic/swiftlint-config": "^2.0.0", | ||
| <<<<<<< HEAD |
There was a problem hiding this comment.
The root manifest has unresolved conflict markers at this location, making package.json invalid JSON and causing package/workspace tooling (e.g., install and scripts) to fail on parse. The same marker pattern is present in other manifests in this commit (cli/package.json, android/package.json, ios/package.json, core/package.json, and lerna.json), so those conflicts also need to be fully resolved.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 15
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
CHANGELOG.md (1)
6-523:⚠️ Potential issue | 🔴 CriticalResolve merge markers and regenerate changelog via CI/CD
CHANGELOG.mdstill contains conflict markers (<<<<<<<,=======,>>>>>>>) between Line 6 and Line 523, which breaks the file and leaves competing histories in place. Please remove manual conflict content and regenerate this file using the repo’s automated changelog workflow instead of hand-editing.As per coding guidelines, "
CHANGELOG.md: Do not manually editCHANGELOG.md; it is managed automatically by CI/CD".🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@CHANGELOG.md` around lines 6 - 523, The CHANGELOG.md file contains unresolved Git conflict markers (<<<<<<<, =======, >>>>>>>) that must be removed; revert any manual edits in CHANGELOG.md, re-run the repository's automated changelog generation workflow (the CI/CD "changelog" or release generation job) to regenerate a clean CHANGELOG.md, verify the generated file contains only the intended release sections (no conflict markers), and commit/push the regenerated file instead of hand-editing CHANGELOG.md.android/CHANGELOG.md (1)
6-252:⚠️ Potential issue | 🟠 MajorResolve the leftover merge-conflict block.
Lines 6-252 still contain
<<<<<<<,=======, and>>>>>>>, so the Android changelog is malformed. The markdownlint heading errors are just a downstream symptom; this section needs an actual merge resolution before release.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@android/CHANGELOG.md` around lines 6 - 252, Resolve the Git merge conflict in the Android changelog by removing the conflict markers (<<<<<<< HEAD, =======, >>>>>>> upstream/main) and producing a single coherent changelog section; reconcile the two competing blocks (the local [8.0.8] / older capacitor-plus entries and the upstream [8.3.0]/[8.2.0] entries) into the intended final content (keep the correct release headings and commit/issue lines you want to publish) so the file no longer contains conflict markers and markdown headings are valid.cli/CHANGELOG.md (1)
6-280:⚠️ Potential issue | 🟠 MajorReconcile this changelog conflict instead of committing the conflict block.
The
HEAD/upstream/mainmarkers are still present, so the release history is currently duplicated/broken and the markdown warnings in this section are just fallout from that. Please merge the two histories cleanly before shipping so the changelog reflects a single coherent release line.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@cli/CHANGELOG.md` around lines 6 - 280, The changelog contains unmerged git conflict markers (<<<<<<<, =======, >>>>>>>) leaving duplicated release histories (e.g., the HEAD block starting with "## [8.0.8]" and the upstream/main block starting with "# [8.3.0]"); remove the conflict markers and merge the two histories into a single coherent timeline by reconciling duplicate or overlapping entries (choose the correct ordering and keep one copy of each release entry such as the 8.0.x and 8.3.0 sections), ensuring markdown headings and indentation remain valid and there are no leftover markers like "HEAD" or "upstream/main".
🧹 Nitpick comments (1)
cli/src/tasks/update.ts (1)
52-52: Prefer additive check composition to avoid future overwrite risk.Using assignment here can discard previously accumulated checks if this function grows.
♻️ Proposed refactor
- checks = await getCommonChecks(config); + checks.push(...(await getCommonChecks(config)));🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@cli/src/tasks/update.ts` at line 52, Assignment to the local variable "checks" with "checks = await getCommonChecks(config)" can overwrite previously accumulated checks; instead append the returned checks to the existing collection (e.g., use checks.push(...returned) or checks = checks.concat(returned)) so that getCommonChecks(config)'s results are added rather than replacing "checks" — locate the usage of the "checks" variable and the call to getCommonChecks(config) and change the assignment to an additive merge.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/publish-ios.yml:
- Around line 21-24: The workflow forces checkout of main which ignores the
triggering ref; update the actions/checkout step (the uses: actions/checkout@v5
entry and the ref: 'main' setting) to stop pinning to main — remove the
hardcoded ref or set it to the triggering ref (for example use the workflow
expression like github.ref or an input variable) so the job checks out the
commit/tag/branch that triggered the run instead of always publishing main.
- Around line 15-17: The workflow hardcodes Xcode via "xcode-select --switch
/Applications/Xcode_26.0.app", which is fragile; change it to dynamically detect
and switch to the runner's default Xcode instead (use the output of xcode-select
-p or xcrun --version / xcrun --show-sdk-path to determine the active developer
path) and use that detected path when invoking xcode-select and xcodebuild/xcrun
commands (replace the literal path in the xcode-select --switch step and ensure
subsequent xcrun/xcodebuild steps rely on the detected developer path).
In `@android/capacitor/src/main/java/com/getcapacitor/plugin/SystemBars.java`:
- Around line 218-224: The fallback safe-area CSS is being computed from
newInsets (which were zeroed via WindowInsetsCompat.Builder) so all
--safe-area-inset-* become 0; change the call that computes/injects the CSS to
use the original insets object instead of newInsets (i.e., call
calcSafeAreaInsets(insets) and pass those values to injectSafeAreaCSS) while
keeping newInsets for any other logic that needs the modified insets.
- Line 280: getThemeColor currently returns typedValue.data blindly, which fails
when android.R.attr.windowBackground is a reference; update getThemeColor to
inspect typedValue.type and handle three cases: if type is a color
(TYPE_FIRST_COLOR_INT..TYPE_LAST_COLOR_INT) return typedValue.data; if type is
TYPE_REFERENCE resolve the resource via ContextCompat.getDrawable(getContext(),
typedValue.resourceId) and if the drawable is a ColorDrawable return its color;
otherwise (non-color drawable) fall back to a safe default color. Ensure callers
like getActivity().getWindow().getDecorView().setBackgroundColor(...) receive an
actual color int, and use typedValue.resourceId when resolving references.
In `@android/capacitor/src/main/java/com/getcapacitor/WebViewLocalServer.java`:
- Around line 342-345: The lookup for the Range header in WebViewLocalServer
uses a case-sensitive get on requestHeaders and only checks "Range" and "range",
which misses other case variants; replace that assignment so you iterate
requestHeaders (or use a helper like getHeaderIgnoreCase) and find the header
key matching equalsIgnoreCase("Range") then set rangeString to its value
(falling back to null if none) before the existing partial-content logic so all
case permutations (e.g., "RANGE", "RaNgE") are handled.
In `@android/package.json`:
- Around line 2-14: The package.json contains unresolved Git conflict markers
(<<<<<<<, =======, >>>>>>>) causing invalid JSON; remove the markers and pick
one consistent package identity (either "@capacitor-plus/android" or
"@capacitor/android") and apply it consistently across the manifest fields
(name, version, description, homepage, author) and any peerDependency namespaces
(ensure "@capacitor-plus/*" vs "@capacitor/*" is uniform). Also locate the other
conflicting block later in the file (the similar chunk around the
peerDependencies/author section) and make the same choice so JSON is valid and
CI no longer fails with EJSONPARSE.
In `@cli/package.json`:
- Around line 9-13: The package.json "name" field was changed to
"@capacitor/cli" which will publish under the upstream Capacitor identity — if
this fork is intended to be Capacitor+ restore or set the scoped package name to
your fork (e.g., "@cap-go/capacitor-plus" or the agreed fork scope) and update
related metadata fields ("homepage", "author", "repository", "bugs")
accordingly; if the change was intentional, add a comment/PR note and ensure
repository and issue tracker settings match the upstream package to avoid
accidental publish under the wrong identity.
- Around line 2-14: package.json contains Git conflict markers (<<<<<<<,
=======, >>>>>>>) around the top-level metadata causing EJSONPARSE; remove the
conflict markers and duplicate blocks and leave a single valid JSON object for
the fields "name", "version", "description", "homepage", and "author" (e.g.,
keep the intended upstream values or the capacitor-plus values consistently),
ensure commas and quotes are correct so the file parses, then run a JSON lint or
npm install to verify; locate and fix the conflict in the package.json header
where the markers surround the name/version/description/homepage/author entries.
In `@cli/src/declarations.ts`:
- Around line 533-535: Fix the typo in the public config documentation comment:
replace the misspelled word "throughrouly" with "thoroughly" in the comment
block that currently reads "If you need to set this property to 6.0 or higher,
make sure to throughrouly test your iOS app." (search for the string
"throughrouly" in cli/src/declarations.ts to locate the comment).
In `@cli/src/index.ts`:
- Around line 30-38: The getPackageManager function currently coerces any
non-'cocoapods' input to 'SPM' — instead validate allowed values and fail fast:
update getPackageManager to explicitly handle known options ('cocoapods' ->
preserve existing bundler check and return 'Cocoapods' or 'bundler' when
applicable, 'spm' -> return 'SPM', and optionally accept 'bundler' -> return
'bundler' if that is a supported direct input) and throw a clear error for any
other value (include the invalid value in the message). Apply the same explicit
validation logic to the other occurrences referenced (the blocks around lines
318-320 and 327) so typos no longer silently map to SPM.
In `@cli/src/ios/update.ts`:
- Around line 133-145: The install guard currently checks isInstalled('pod')
instead of the configured binary, so replace the hard-coded check with a check
against the configured podPath (the const podPath from config.ios.podPath)
before deciding to skip; in other words, call isInstalled(podPath) (or otherwise
validate podPath) and only warn/skip if that configured path is not installed,
and continue to call runCommand(podPath, ['install', ...]) when podPath is
valid; update the branch that uses isInstalled('pod') to reference podPath and
preserve the bundler branch that uses runCommand('bundle', ...) unchanged.
In `@cli/src/tasks/run.ts`:
- Around line 113-115: The log message inside the logger.info call in run.ts has
a typo ("live reload listing"); update the string used in the logger.info
invocation (the template that references options.https, options.host,
options.port) to read "live reload listening" instead of "live reload listing"
so the message becomes "App running with live reload listening for: ...".
In `@cli/src/util/spm.ts`:
- Around line 100-106: Remove the raw merge conflict markers (<<<<<<<, =======,
>>>>>>>) and reconcile the two branches by keeping the newer SPM additions: use
getMajoriOSVersion(config) to set iosVersion, and also initialize packageTraits
(from config.app.extConfig.experimental?.ios?.spm?.packageTraits ?? {}) and
swiftToolsVersion (defaulting to '5.9'); delete the old getMajorMinoriOSVersion
usage and the conflict markers so the file parses and the new SPM variables
(iosVersion, packageTraits, swiftToolsVersion) are present.
In `@ios/Capacitor/Capacitor/CAPBridgedJSTypes.m`:
- Line 32: The method implementation for - (NSArray *
_Nullable)getArray:(NSString * _Nonnull)key defaultValue:(NSArray *
_Nullable)defaultValue in CAPBridgedJSTypes.m has a stray semicolon before the
opening brace; remove that semicolon so the method signature is immediately
followed by the { to restore valid Objective-C method syntax and allow the file
to compile.
In `@ios/package.json`:
- Around line 2-14: The package.json contains unresolved Git conflict markers
around the package metadata; remove the conflict markers (<<<<<<<, =======,
>>>>>>>) and choose a single consistent set of values for the "name", "version",
"description", "homepage", and "author" fields so the manifest matches the
fork's intended metadata (e.g., keep either the `@capacitor-plus/ios` entries or
the upstream `@capacitor/ios` entries), and also resolve the second conflict block
later in the file so the JSON parses and npm install succeeds.
---
Outside diff comments:
In `@android/CHANGELOG.md`:
- Around line 6-252: Resolve the Git merge conflict in the Android changelog by
removing the conflict markers (<<<<<<< HEAD, =======, >>>>>>> upstream/main) and
producing a single coherent changelog section; reconcile the two competing
blocks (the local [8.0.8] / older capacitor-plus entries and the upstream
[8.3.0]/[8.2.0] entries) into the intended final content (keep the correct
release headings and commit/issue lines you want to publish) so the file no
longer contains conflict markers and markdown headings are valid.
In `@CHANGELOG.md`:
- Around line 6-523: The CHANGELOG.md file contains unresolved Git conflict
markers (<<<<<<<, =======, >>>>>>>) that must be removed; revert any manual
edits in CHANGELOG.md, re-run the repository's automated changelog generation
workflow (the CI/CD "changelog" or release generation job) to regenerate a clean
CHANGELOG.md, verify the generated file contains only the intended release
sections (no conflict markers), and commit/push the regenerated file instead of
hand-editing CHANGELOG.md.
In `@cli/CHANGELOG.md`:
- Around line 6-280: The changelog contains unmerged git conflict markers
(<<<<<<<, =======, >>>>>>>) leaving duplicated release histories (e.g., the HEAD
block starting with "## [8.0.8]" and the upstream/main block starting with "#
[8.3.0]"); remove the conflict markers and merge the two histories into a single
coherent timeline by reconciling duplicate or overlapping entries (choose the
correct ordering and keep one copy of each release entry such as the 8.0.x and
8.3.0 sections), ensuring markdown headings and indentation remain valid and
there are no leftover markers like "HEAD" or "upstream/main".
---
Nitpick comments:
In `@cli/src/tasks/update.ts`:
- Line 52: Assignment to the local variable "checks" with "checks = await
getCommonChecks(config)" can overwrite previously accumulated checks; instead
append the returned checks to the existing collection (e.g., use
checks.push(...returned) or checks = checks.concat(returned)) so that
getCommonChecks(config)'s results are added rather than replacing "checks" —
locate the usage of the "checks" variable and the call to
getCommonChecks(config) and change the assignment to an additive merge.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: b70aaa35-3712-4c88-b831-26d71a39d1b9
📒 Files selected for processing (52)
.github/ISSUE_TEMPLATE/config.yml.github/ISSUE_TEMPLATE/feature-request.yml.github/ionic-issue-bot.yml.github/workflows/needs-reply.yml.github/workflows/publish-ios.yml.github/workflows/test.ymlCHANGELOG.mdandroid/CHANGELOG.mdandroid/capacitor/src/main/assets/native-bridge.jsandroid/capacitor/src/main/java/com/getcapacitor/Bridge.javaandroid/capacitor/src/main/java/com/getcapacitor/BridgeActivity.javaandroid/capacitor/src/main/java/com/getcapacitor/WebViewLocalServer.javaandroid/capacitor/src/main/java/com/getcapacitor/plugin/SystemBars.javaandroid/package.jsoncli/CHANGELOG.mdcli/package.jsoncli/src/config.tscli/src/declarations.tscli/src/definitions.tscli/src/index.tscli/src/ios/build.tscli/src/ios/common.tscli/src/ios/doctor.tscli/src/ios/open.tscli/src/ios/run.tscli/src/ios/update.tscli/src/tasks/add.tscli/src/tasks/migrate-spm.tscli/src/tasks/migrate.tscli/src/tasks/run.tscli/src/tasks/sourcemaps.tscli/src/tasks/sync.tscli/src/tasks/update.tscli/src/util/livereload.tscli/src/util/spm.tscli/src/util/template.tscore/CHANGELOG.mdcore/native-bridge.tscore/package.jsoncore/src/core-plugins.tscore/system-bars.mdios-spm-template/App/CapApp-SPM/README.mdios/CHANGELOG.mdios/Capacitor/Capacitor/CAPBridgeProtocol.swiftios/Capacitor/Capacitor/CAPBridgedJSTypes.hios/Capacitor/Capacitor/CAPBridgedJSTypes.mios/Capacitor/Capacitor/CapacitorBridge.swiftios/Capacitor/Capacitor/assets/native-bridge.jsios/package.jsonlerna.jsonpackage.jsonscripts/pack-cli-assets.mjs
💤 Files with no reviewable changes (1)
- .github/ISSUE_TEMPLATE/feature-request.yml
👮 Files not reviewed due to content moderation or server errors (10)
- ios/Capacitor/Capacitor/CAPBridgeProtocol.swift
- ios/Capacitor/Capacitor/CapacitorBridge.swift
- .github/ISSUE_TEMPLATE/config.yml
- .github/ionic-issue-bot.yml
- lerna.json
- package.json
- .github/workflows/needs-reply.yml
- ios/CHANGELOG.md
- core/CHANGELOG.md
- core/package.json
| - run: sudo xcode-select --switch /Applications/Xcode_26.0.app | ||
| - run: xcrun simctl list > /dev/null | ||
| - run: xcodebuild -downloadPlatform iOS |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does the GitHub Actions macos-15 runner image currently include /Applications/Xcode_26.0.app, and what Xcode app bundle paths are officially documented as preinstalled?
💡 Result:
No, the GitHub Actions macos-15 runner image does not include /Applications/Xcode_26.0.app as a primary bundle path. It includes /Applications/Xcode_26.0.1.app with a symlink at /Applications/Xcode_26.0.app. The officially documented preinstalled Xcode app bundle paths on macos-15 (current image version 20260330.0336.1, macOS 15.7.5) are: - Xcode 26.3 (17C529): /Applications/Xcode_26.3.app (symlink: /Applications/Xcode_26.3.0.app) - Xcode 26.2 (17C52): /Applications/Xcode_26.2.app (symlink: /Applications/Xcode_26.2.0.app) - Xcode 26.1.1 (17B100): /Applications/Xcode_26.1.1.app (symlink: /Applications/Xcode_26.1.app) - Xcode 26.0.1 (17A400): /Applications/Xcode_26.0.1.app (symlink: /Applications/Xcode_26.0.app) - Xcode 16.4 (default, 16F6): /Applications/Xcode_16.4.app - Xcode 16.3 (16E140): /Applications/Xcode_16.3.app (symlink: /Applications/Xcode_16.3.0.app) - Xcode 16.0 (16A242d): /Applications/Xcode_16.app (symlinks: /Applications/Xcode_16.0.0.app, /Applications/Xcode_16.0.app, /Applications/Xcode.app) This information comes from the official runner-images repository's macos-15-Readme.md on the main branch, which documents the current production image used by GitHub Actions.
Citations:
- 1: https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md
- 2: https://github.com/actions/runner-images/releases/tag/macos-15/20260303.0227
The hardcoded Xcode path /Applications/Xcode_26.0.app currently exists on macos-15 as a symlink, but relying on it is fragile.
The path resolves via a symlink to /Applications/Xcode_26.0.1.app on the current image. However, hardcoding to a specific version introduces maintenance risk if GitHub Actions removes or restructures that symlink in future runner updates. Consider using a dynamic approach (e.g., detecting the default Xcode via xcode-select -p or xcrun --version) to avoid coupled workflows.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish-ios.yml around lines 15 - 17, The workflow
hardcodes Xcode via "xcode-select --switch /Applications/Xcode_26.0.app", which
is fragile; change it to dynamically detect and switch to the runner's default
Xcode instead (use the output of xcode-select -p or xcrun --version / xcrun
--show-sdk-path to determine the active developer path) and use that detected
path when invoking xcode-select and xcodebuild/xcrun commands (replace the
literal path in the xcode-select --switch step and ensure subsequent
xcrun/xcodebuild steps rely on the detected developer path).
| - uses: actions/checkout@v5 | ||
| with: | ||
| fetch-depth: 0 | ||
| ref: 'main' |
There was a problem hiding this comment.
Don't force the workflow to publish main.
This release job ignores the triggering ref and always checks out main, so a run from another branch, tag, or reusable-workflow caller can publish the wrong sources.
Proposed fix
- uses: actions/checkout@v5
with:
fetch-depth: 0
- ref: 'main'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - uses: actions/checkout@v5 | |
| with: | |
| fetch-depth: 0 | |
| ref: 'main' | |
| - uses: actions/checkout@v5 | |
| with: | |
| fetch-depth: 0 |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish-ios.yml around lines 21 - 24, The workflow forces
checkout of main which ignores the triggering ref; update the actions/checkout
step (the uses: actions/checkout@v5 entry and the ref: 'main' setting) to stop
pinning to main — remove the hardcoded ref or set it to the triggering ref (for
example use the workflow expression like github.ref or an input variable) so the
job checks out the commit/tag/branch that triggered the run instead of always
publishing main.
| WindowInsetsCompat newInsets = new WindowInsetsCompat.Builder(insets) | ||
| .setInsets(WindowInsetsCompat.Type.systemBars() | WindowInsetsCompat.Type.displayCutout(), Insets.of(0, 0, 0, 0)) | ||
| .build(); | ||
|
|
||
| if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM && hasViewportCover && insetHandlingEnabled) { | ||
| Insets safeAreaInsets = calcSafeAreaInsets(newInsets); | ||
| injectSafeAreaCSS(safeAreaInsets.top, safeAreaInsets.right, safeAreaInsets.bottom, safeAreaInsets.left); |
There was a problem hiding this comment.
Use the original insets when injecting fallback safe-area CSS.
Line 223 computes the CSS values from newInsets, but Lines 218-220 have already zeroed the system bar and cutout insets. On the old-WebView fallback path, that turns every --safe-area-inset-* into 0, so the workaround stops working on the devices this branch is meant to fix.
Suggested fix
WindowInsetsCompat newInsets = new WindowInsetsCompat.Builder(insets)
.setInsets(WindowInsetsCompat.Type.systemBars() | WindowInsetsCompat.Type.displayCutout(), Insets.of(0, 0, 0, 0))
.build();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM && hasViewportCover && insetHandlingEnabled) {
- Insets safeAreaInsets = calcSafeAreaInsets(newInsets);
+ Insets safeAreaInsets = calcSafeAreaInsets(insets);
injectSafeAreaCSS(safeAreaInsets.top, safeAreaInsets.right, safeAreaInsets.bottom, safeAreaInsets.left);
}
return newInsets;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@android/capacitor/src/main/java/com/getcapacitor/plugin/SystemBars.java`
around lines 218 - 224, The fallback safe-area CSS is being computed from
newInsets (which were zeroed via WindowInsetsCompat.Builder) so all
--safe-area-inset-* become 0; change the call that computes/injects the CSS to
use the original insets object instead of newInsets (i.e., call
calcSafeAreaInsets(insets) and pass those values to injectSafeAreaCSS) while
keeping newInsets for any other logic that needs the modified insets.
| windowInsetsControllerCompat.setAppearanceLightNavigationBars(!style.equals(STYLE_DARK)); | ||
| } | ||
|
|
||
| getActivity().getWindow().getDecorView().setBackgroundColor(getThemeColor(getContext(), android.R.attr.windowBackground)); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, locate and examine the SystemBars.java file
fd SystemBars.java android/Repository: Cap-go/capacitor-plus
Length of output: 136
🏁 Script executed:
# Check the file size and content around the specified lines
wc -l android/capacitor/src/main/java/com/getcapacitor/plugin/SystemBars.javaRepository: Cap-go/capacitor-plus
Length of output: 140
🏁 Script executed:
# Examine the relevant sections - lines 270-330 to see context
sed -n '270,330p' android/capacitor/src/main/java/com/getcapacitor/plugin/SystemBars.javaRepository: Cap-go/capacitor-plus
Length of output: 2491
🌐 Web query:
Android TypedValue.data resourceId inline color vs drawable reference behavior
💡 Result:
In Android's TypedValue (used with Resources.getValue(id, value, resolveRefs=false)), the .data and .resourceId fields behave differently depending on whether the resource is an inline color value or a drawable reference. For an inline color resource (defined in res/values/colors.xml as #FF0000): - type is a color int type (TYPE_INT_COLOR_ARGB8=0x1c, etc., between TYPE_FIRST_COLOR_INT=0x1c and TYPE_LAST_COLOR_INT=0x1f) - .data holds the parsed 32-bit ARGB color integer value (e.g., 0xffff0000) - .resourceId == 0 (no separate resource ID needed, as the value is inline) For a drawable resource reference (e.g., R.drawable.myimage, typically a bitmap or vector in res/drawable/): - type == TYPE_REFERENCE (0x01) - .data holds the resource ID (same value as R.drawable.myimage) - .resourceId holds the resource ID (same as .data) To distinguish: - Check value.type: color range means inline color (.data is the color int); TYPE_REFERENCE means resource ref (.data/.resourceId is the ID to load further). This allows code to inspect a resource ID (R.color or R.drawable) and determine if it's directly usable as color (via .data) or needs loading as drawable (via getDrawable(.resourceId)). Examples from common usage: TypedValue value = new TypedValue; resources.getValue(R.id.some_color_or_drawable, value, false); if (value.isColorType) { // or type >= TYPE_FIRST_COLOR_INT && <= TYPE_LAST_COLOR_INT int color = value.data; } else if (value.type == TypedValue.TYPE_REFERENCE) { Drawable d = resources.getDrawable(value.resourceId); }
Citations:
- 1: https://developer.android.com/reference/android/util/TypedValue
- 2: https://android.googlesource.com/platform/frameworks/base/+/6193aa3/core/java/android/util/TypedValue.java
- 3: https://stackoverflow.com/questions/21210825/is-resource-a-color-or-a-drawable
- 4: https://developer.android.com/guide/topics/resources/more-resources
Fix getThemeColor() to properly resolve theme resources based on their type.
The current implementation at lines 313-318 blindly returns typedValue.data without checking the resource type. When android:windowBackground is a drawable or resource reference (not an inline color), typedValue.data contains a resource ID, not a color value. Passing this ID to setBackgroundColor() at line 280 interprets it as RGB, rendering the wrong color.
Validate the type using typedValue.type to distinguish inline colors (TYPE_FIRST_COLOR_INT to TYPE_LAST_COLOR_INT) from references (TYPE_REFERENCE). For references, resolve the actual drawable using ContextCompat.getDrawable() and extract its color if it's a ColorDrawable.
Suggested fix
+import android.graphics.drawable.ColorDrawable;
import android.util.TypedValue;
import android.view.View;
import android.view.Window;
import android.webkit.JavascriptInterface;
import android.webkit.WebView;
@@
import androidx.core.view.ViewCompat;
import androidx.core.view.WindowCompat;
import androidx.core.view.WindowInsetsCompat;
import androidx.core.view.WindowInsetsControllerCompat;
+import androidx.core.content.ContextCompat;
import androidx.webkit.WebViewCompat;
@@
- getActivity().getWindow().getDecorView().setBackgroundColor(getThemeColor(getContext(), android.R.attr.windowBackground));
+ Integer windowBackground = getThemeColor(getContext(), android.R.attr.windowBackground);
+ if (windowBackground != null) {
+ getActivity().getWindow().getDecorView().setBackgroundColor(windowBackground);
+ }
@@
- public int getThemeColor(Context context, int attrRes) {
+ public Integer getThemeColor(Context context, int attrRes) {
TypedValue typedValue = new TypedValue();
Resources.Theme theme = context.getTheme();
- theme.resolveAttribute(attrRes, typedValue, true);
- return typedValue.data;
+ if (!theme.resolveAttribute(attrRes, typedValue, true)) {
+ return null;
+ }
+ if (typedValue.type >= TypedValue.TYPE_FIRST_COLOR_INT && typedValue.type <= TypedValue.TYPE_LAST_COLOR_INT) {
+ return typedValue.data;
+ }
+ if (typedValue.resourceId != 0) {
+ if (ContextCompat.getDrawable(context, typedValue.resourceId) instanceof ColorDrawable colorDrawable) {
+ return colorDrawable.getColor();
+ }
+ }
+ return null;
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@android/capacitor/src/main/java/com/getcapacitor/plugin/SystemBars.java` at
line 280, getThemeColor currently returns typedValue.data blindly, which fails
when android.R.attr.windowBackground is a reference; update getThemeColor to
inspect typedValue.type and handle three cases: if type is a color
(TYPE_FIRST_COLOR_INT..TYPE_LAST_COLOR_INT) return typedValue.data; if type is
TYPE_REFERENCE resolve the resource via ContextCompat.getDrawable(getContext(),
typedValue.resourceId) and if the drawable is a ColorDrawable return its color;
otherwise (non-color drawable) fall back to a safe default color. Ensure callers
like getActivity().getWindow().getDecorView().setBackgroundColor(...) receive an
actual color int, and use typedValue.resourceId when resolving references.
| Map<String, String> requestHeaders = request.getRequestHeaders(); | ||
| String rangeString = requestHeaders.get("Range") != null ? requestHeaders.get("Range") : requestHeaders.get("range"); | ||
|
|
||
| if (rangeString != null) { |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's check the file and surrounding lines
head -n 350 android/capacitor/src/main/java/com/getcapacitor/WebViewLocalServer.java | tail -n 20Repository: Cap-go/capacitor-plus
Length of output: 1022
🏁 Script executed:
# Get more context around lines 342-345
sed -n '330,360p' android/capacitor/src/main/java/com/getcapacitor/WebViewLocalServer.javaRepository: Cap-go/capacitor-plus
Length of output: 1678
🏁 Script executed:
# Check the entire method to understand the context better
sed -n '320,380p' android/capacitor/src/main/java/com/getcapacitor/WebViewLocalServer.javaRepository: Cap-go/capacitor-plus
Length of output: 2778
🏁 Script executed:
# Search for other header lookups in the same file
rg 'getRequestHeaders|requestHeaders\.get' android/capacitor/src/main/java/com/getcapacitor/WebViewLocalServer.javaRepository: Cap-go/capacitor-plus
Length of output: 433
🏁 Script executed:
# Check if there are tests or documentation about header handling
rg -A 3 -B 3 'Range|range.*header' android/Repository: Cap-go/capacitor-plus
Length of output: 4056
🏁 Script executed:
# Look for other header access patterns in the codebase
rg 'getRequestHeaders\(\)' android/ -A 5Repository: Cap-go/capacitor-plus
Length of output: 2478
🏁 Script executed:
# Search for how headers are populated from WebResourceRequest
rg 'WebResourceRequest' android/ -B 2 -A 5Repository: Cap-go/capacitor-plus
Length of output: 14133
Use case-insensitive header matching for Range lookup.
The current approach of checking requestHeaders.get("Range") and requestHeaders.get("range") handles only two cases. HTTP header names are case-insensitive per RFC 7230, so variations like RANGE or RaNgE would bypass the partial-content logic. Iterate through the headers and use equalsIgnoreCase() to match properly:
🔧 Proposed fix
- Map<String, String> requestHeaders = request.getRequestHeaders();
- String rangeString = requestHeaders.get("Range") != null ? requestHeaders.get("Range") : requestHeaders.get("range");
+ Map<String, String> requestHeaders = request.getRequestHeaders();
+ String rangeString = null;
+ for (Map.Entry<String, String> header : requestHeaders.entrySet()) {
+ if ("Range".equalsIgnoreCase(header.getKey())) {
+ rangeString = header.getValue();
+ break;
+ }
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Map<String, String> requestHeaders = request.getRequestHeaders(); | |
| String rangeString = requestHeaders.get("Range") != null ? requestHeaders.get("Range") : requestHeaders.get("range"); | |
| if (rangeString != null) { | |
| Map<String, String> requestHeaders = request.getRequestHeaders(); | |
| String rangeString = null; | |
| for (Map.Entry<String, String> header : requestHeaders.entrySet()) { | |
| if ("Range".equalsIgnoreCase(header.getKey())) { | |
| rangeString = header.getValue(); | |
| break; | |
| } | |
| } | |
| if (rangeString != null) { |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@android/capacitor/src/main/java/com/getcapacitor/WebViewLocalServer.java`
around lines 342 - 345, The lookup for the Range header in WebViewLocalServer
uses a case-sensitive get on requestHeaders and only checks "Range" and "range",
which misses other case variants; replace that assignment so you iterate
requestHeaders (or use a helper like getHeaderIgnoreCase) and find the header
key matching equalsIgnoreCase("Range") then set rangeString to its value
(falling back to null if none) before the existing partial-content logic so all
case permutations (e.g., "RANGE", "RaNgE") are handled.
| const podPath = await config.ios.podPath; | ||
| const useBundler = podPath.startsWith('bundle') && (await isInstalled('bundle')); | ||
| const podCommandExists = await isInstalled('pod'); | ||
| if (useBundler || podCommandExists) { | ||
| if (useBundler) { | ||
| await runCommand('bundle', ['exec', 'pod', 'install', ...(deployment ? ['--deployment'] : [])], { | ||
| cwd: config.ios.nativeProjectDirAbs, | ||
| }); | ||
| } else { | ||
| await runCommand(podPath, ['install', ...(deployment ? ['--deployment'] : [])], { | ||
| cwd: config.ios.nativeProjectDirAbs, | ||
| }); | ||
| } | ||
| const useBundler = (await config.ios.packageManager) === 'bundler'; | ||
| if (useBundler) { | ||
| await runCommand('bundle', ['exec', 'pod', 'install', ...(deployment ? ['--deployment'] : [])], { | ||
| cwd: config.ios.nativeProjectDirAbs, | ||
| }); | ||
| } else if (await isInstalled('pod')) { | ||
| await runCommand(podPath, ['install', ...(deployment ? ['--deployment'] : [])], { | ||
| cwd: config.ios.nativeProjectDirAbs, | ||
| }); | ||
| } else { | ||
| logger.warn('Skipping pod install because CocoaPods is not installed'); | ||
| } |
There was a problem hiding this comment.
Honor the configured CocoaPods command in the install guard.
Line 139 hard-codes isInstalled('pod'), but the command you actually run comes from config.ios.podPath. That breaks setups using CAPACITOR_COCOAPODS_PATH when pod is not on PATH: this branch warns and skips pod install even though the configured binary is valid.
Proposed fix
const podPath = await config.ios.podPath;
const useBundler = (await config.ios.packageManager) === 'bundler';
+ const hasPod =
+ podPath.includes('/') || podPath.includes('\\')
+ ? await pathExists(podPath)
+ : await isInstalled(podPath);
if (useBundler) {
await runCommand('bundle', ['exec', 'pod', 'install', ...(deployment ? ['--deployment'] : [])], {
cwd: config.ios.nativeProjectDirAbs,
});
- } else if (await isInstalled('pod')) {
+ } else if (hasPod) {
await runCommand(podPath, ['install', ...(deployment ? ['--deployment'] : [])], {
cwd: config.ios.nativeProjectDirAbs,
});
} else {
logger.warn('Skipping pod install because CocoaPods is not installed');🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@cli/src/ios/update.ts` around lines 133 - 145, The install guard currently
checks isInstalled('pod') instead of the configured binary, so replace the
hard-coded check with a check against the configured podPath (the const podPath
from config.ios.podPath) before deciding to skip; in other words, call
isInstalled(podPath) (or otherwise validate podPath) and only warn/skip if that
configured path is not installed, and continue to call runCommand(podPath,
['install', ...]) when podPath is valid; update the branch that uses
isInstalled('pod') to reference podPath and preserve the bundler branch that
uses runCommand('bundle', ...) unchanged.
| logger.info( | ||
| `App running with live reload listing for: http://${options.host}:${options.port}. Press Ctrl+C to quit.`, | ||
| `App running with live reload listing for: ${options.https ? 'https' : 'http'}://${options.host}${options.port ? `:${options.port}` : ''}. Press Ctrl+C to quit.`, | ||
| ); |
There was a problem hiding this comment.
Fix the live-reload status typo.
Line 114 says “live reload listing”; that should be “live reload listening”.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@cli/src/tasks/run.ts` around lines 113 - 115, The log message inside the
logger.info call in run.ts has a typo ("live reload listing"); update the string
used in the logger.info invocation (the template that references options.https,
options.host, options.port) to read "live reload listening" instead of "live
reload listing" so the message becomes "App running with live reload listening
for: ...".
| <<<<<<< HEAD | ||
| const iosVersion = getMajorMinoriOSVersion(config); | ||
| ======= | ||
| const iosVersion = getMajoriOSVersion(config); | ||
| const packageTraits = config.app.extConfig.experimental?.ios?.spm?.packageTraits ?? {}; | ||
| const swiftToolsVersion = config.app.extConfig.experimental?.ios?.spm?.swiftToolsVersion ?? '5.9'; | ||
| >>>>>>> upstream/main |
There was a problem hiding this comment.
Resolve the merge conflict markers before merging.
Lines 100-106 are still raw conflict markers, so this file does not parse and CI will fail before any of the new SPM logic can run.
Suggested fix
-<<<<<<< HEAD
const iosVersion = getMajorMinoriOSVersion(config);
-=======
- const iosVersion = getMajoriOSVersion(config);
const packageTraits = config.app.extConfig.experimental?.ios?.spm?.packageTraits ?? {};
const swiftToolsVersion = config.app.extConfig.experimental?.ios?.spm?.swiftToolsVersion ?? '5.9';
->>>>>>> upstream/main📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <<<<<<< HEAD | |
| const iosVersion = getMajorMinoriOSVersion(config); | |
| ======= | |
| const iosVersion = getMajoriOSVersion(config); | |
| const packageTraits = config.app.extConfig.experimental?.ios?.spm?.packageTraits ?? {}; | |
| const swiftToolsVersion = config.app.extConfig.experimental?.ios?.spm?.swiftToolsVersion ?? '5.9'; | |
| >>>>>>> upstream/main | |
| const iosVersion = getMajorMinoriOSVersion(config); | |
| const packageTraits = config.app.extConfig.experimental?.ios?.spm?.packageTraits ?? {}; | |
| const swiftToolsVersion = config.app.extConfig.experimental?.ios?.spm?.swiftToolsVersion ?? '5.9'; |
🧰 Tools
🪛 Biome (2.4.10)
[error] 100-100: Expected a statement but instead found '<<<<<<< HEAD'.
(parse)
[error] 102-102: Expected a statement but instead found '======='.
(parse)
[error] 106-106: Expected a statement but instead found '>>>>>>> upstream/main'.
(parse)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@cli/src/util/spm.ts` around lines 100 - 106, Remove the raw merge conflict
markers (<<<<<<<, =======, >>>>>>>) and reconcile the two branches by keeping
the newer SPM additions: use getMajoriOSVersion(config) to set iosVersion, and
also initialize packageTraits (from
config.app.extConfig.experimental?.ios?.spm?.packageTraits ?? {}) and
swiftToolsVersion (defaulting to '5.9'); delete the old getMajorMinoriOSVersion
usage and the conflict markers so the file parses and the new SPM variables
(iosVersion, packageTraits, swiftToolsVersion) are present.
| return defaultValue; | ||
| } | ||
|
|
||
| - (NSArray * _Nullable)getArray:(NSString * _Nonnull)key defaultValue:(NSArray * _Nullable)defaultValue; { |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify there are no Objective-C method implementations with ';' before '{'
rg -nP '^\s*-\s*\([^)]*\)[^{\n]*;\s*\{' ios/Capacitor/Capacitor/CAPBridgedJSTypes.m
# Expected after fix: no matchesRepository: Cap-go/capacitor-plus
Length of output: 174
Remove the stray ; before { in the method implementation.
Line 32 has an invalid semicolon between the method signature and the opening brace, which will fail compilation.
Proposed fix
-- (NSArray * _Nullable)getArray:(NSString * _Nonnull)key defaultValue:(NSArray * _Nullable)defaultValue; {
+- (NSArray * _Nullable)getArray:(NSString * _Nonnull)key defaultValue:(NSArray * _Nullable)defaultValue {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - (NSArray * _Nullable)getArray:(NSString * _Nonnull)key defaultValue:(NSArray * _Nullable)defaultValue; { | |
| - (NSArray * _Nullable)getArray:(NSString * _Nonnull)key defaultValue:(NSArray * _Nullable)defaultValue { |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@ios/Capacitor/Capacitor/CAPBridgedJSTypes.m` at line 32, The method
implementation for - (NSArray * _Nullable)getArray:(NSString * _Nonnull)key
defaultValue:(NSArray * _Nullable)defaultValue in CAPBridgedJSTypes.m has a
stray semicolon before the opening brace; remove that semicolon so the method
signature is immediately followed by the { to restore valid Objective-C method
syntax and allow the file to compile.
| <<<<<<< HEAD | ||
| "name": "@capacitor-plus/ios", | ||
| "version": "8.0.8", | ||
| "description": "Capacitor+: Enhanced Capacitor with automated upstream sync - Cross-platform apps with JavaScript and the web", | ||
| "homepage": "https://capgo.app/docs/plugins/capacitor-plus/", | ||
| "author": "Capgo Team <support@capgo.app> (https://capgo.app)", | ||
| ======= | ||
| "name": "@capacitor/ios", | ||
| "version": "8.3.0", | ||
| "description": "Capacitor: Cross-platform apps with JavaScript and the web", | ||
| "homepage": "https://capacitorjs.com", | ||
| "author": "Ionic Team <hi@ionic.io> (https://ionic.io)", | ||
| >>>>>>> upstream/main |
There was a problem hiding this comment.
This package.json still has unresolved conflict markers.
The file will not parse until the HEAD/upstream/main markers are removed, and that is enough to break npm install for the workspace. Please resolve both blocks together so the package name/version/peer dependency choice is internally consistent with the rest of the fork metadata in this manifest.
Also applies to: 36-41
🧰 Tools
🪛 Biome (2.4.10)
[error] 2-2: unexpected character <
(parse)
[error] 2-2: unexpected character <
(parse)
[error] 2-2: unexpected character <
(parse)
[error] 2-2: unexpected character <
(parse)
[error] 2-2: unexpected character <
(parse)
[error] 2-2: unexpected character <
(parse)
[error] 2-2: unexpected character <
(parse)
[error] 2-2: String values must be double quoted.
(parse)
[error] 3-3: End of file expected
(parse)
[error] 3-3: End of file expected
(parse)
[error] 3-3: End of file expected
(parse)
[error] 3-3: End of file expected
(parse)
[error] 4-4: End of file expected
(parse)
[error] 4-4: End of file expected
(parse)
[error] 4-4: End of file expected
(parse)
[error] 4-4: End of file expected
(parse)
[error] 5-5: End of file expected
(parse)
[error] 5-5: End of file expected
(parse)
[error] 5-5: End of file expected
(parse)
[error] 5-5: End of file expected
(parse)
[error] 6-6: End of file expected
(parse)
[error] 6-6: End of file expected
(parse)
[error] 6-6: End of file expected
(parse)
[error] 6-6: End of file expected
(parse)
[error] 7-7: End of file expected
(parse)
[error] 7-7: End of file expected
(parse)
[error] 7-7: End of file expected
(parse)
[error] 7-8: End of file expected
(parse)
[error] 8-8: unexpected character =
(parse)
[error] 8-8: unexpected character =
(parse)
[error] 8-8: unexpected character =
(parse)
[error] 8-8: unexpected character =
(parse)
[error] 8-8: unexpected character =
(parse)
[error] 8-8: unexpected character =
(parse)
[error] 8-8: unexpected character =
(parse)
[error] 9-9: End of file expected
(parse)
[error] 9-9: End of file expected
(parse)
[error] 9-9: End of file expected
(parse)
[error] 9-9: End of file expected
(parse)
[error] 10-10: End of file expected
(parse)
[error] 10-10: End of file expected
(parse)
[error] 10-10: End of file expected
(parse)
[error] 10-10: End of file expected
(parse)
[error] 11-11: End of file expected
(parse)
[error] 11-11: End of file expected
(parse)
[error] 11-11: End of file expected
(parse)
[error] 11-11: End of file expected
(parse)
[error] 12-12: End of file expected
(parse)
[error] 12-12: End of file expected
(parse)
[error] 12-12: End of file expected
(parse)
[error] 12-12: End of file expected
(parse)
[error] 13-13: End of file expected
(parse)
[error] 13-13: End of file expected
(parse)
[error] 13-13: End of file expected
(parse)
[error] 13-14: End of file expected
(parse)
[error] 14-14: unexpected character >
(parse)
[error] 14-14: unexpected character >
(parse)
[error] 14-14: unexpected character >
(parse)
[error] 14-14: unexpected character >
(parse)
[error] 14-14: unexpected character >
(parse)
[error] 14-14: unexpected character >
(parse)
[error] 14-14: unexpected character >
(parse)
[error] 14-14: unexpected character /
(parse)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@ios/package.json` around lines 2 - 14, The package.json contains unresolved
Git conflict markers around the package metadata; remove the conflict markers
(<<<<<<<, =======, >>>>>>>) and choose a single consistent set of values for the
"name", "version", "description", "homepage", and "author" fields so the
manifest matches the fork's intended metadata (e.g., keep either the
`@capacitor-plus/ios` entries or the upstream `@capacitor/ios` entries), and also
resolve the second conflict block later in the file so the JSON parses and npm
install succeeds.
14 participants
Merge Conflict Resolution Required
The automatic sync of the
plusbranch with upstream main encountered merge conflicts.What happened
Action needed: Review the branch and resolve any remaining concerns before merging.
This PR was created automatically by the Capacitor+ sync workflow
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Chores