fix(ios): harden Podfile widget-target generation#212
Merged
Conversation
- Raise a clear error in the generated Ruby when @use-voltra/ios-client fails to resolve at pod-install time, instead of silently producing a garbage pod path. - Canonicalize the resolved podspec path with File.realpath so relative path computation survives pnpm/bun symlinked node_modules. - Wrap the generated target block in @voltra-widget-target BEGIN/END markers and replace it in place on each prebuild (instead of skipping regeneration via a substring check), so plugin upgrades actually reach Podfiles from older versions. Also detects and replaces the legacy (pre-marker) block shape for a clean one-time upgrade path. - Extract the pure upsertWidgetTarget(contents, targetName) transform, following the android-client gradle.ts pattern, and cover it with colocated node tests.
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
1 participant
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.
What is this?
This PR hardens the Podfile block the Voltra plugin generates for the widget extension target. Previously the block was appended with no delimiters and located by a brittle regex, and the embedded Ruby resolved the
VoltraWidgetpodspec path in ways that could silently produce a broken Podfile — most visibly for pnpm and bun users, whose symlinkednode_moduleslayouts defeat naive path resolution (#79).How does it work?
# @voltra-widget-target BEGIN/ENDmarkers. On every prebuild the plugin upserts the marked block: a fresh Podfile gets it appended, an existing marked block is replaced in place, and blocks written by previous plugin versions are recognized via a legacy pattern and migrated to the marked form. Re-runs are idempotent, and renaming the widget target updates the block instead of duplicating it.@use-voltra/ios-clientcannot be resolved from the project root,pod installaborts with an actionable Voltra-prefixed error rather than generating a target pointing at an empty path.File.realpath, so the symlink chains produced by pnpm and bun resolve to the real package location CocoaPods can work with.The transformation is exposed as a pure
upsertWidgetTarget(contents, targetName)and covered by seven tests: fresh append, marked-block replacement, legacy-block migration, idempotency, renamed target, multiple app targets, and a Podfile without a trailing newline.Why is this useful?
realpath) or an immediate, self-explanatory error atpod installtime — not a cryptic failure later in the build (pod install fails with "multiple dependencies with different sources for VoltraWidget" (pnpm) #79).