Use indexed watch folder paths for external assets - #1892
Draft
robhogan wants to merge 4 commits into
Draft
Conversation
## Summary `metro-symbolicate` aborts with `TypeError: Line must be greater than or equal to 1, got 0` and emits nothing at all if any frame in the input has line 0. One such frame discards the whole trace, which is why folks in #966 are hand-editing their stack traces first. Line 0 isn't necessarily malformed input - it's how some crash reporters, Crashlytics for example, represent a frame with no JS source position once every frame has been normalised to `file:line:column`, rendering `[native code]` as `[native code]:0:0`. We already accept the un-normalised form: `symbolicate()`'s regex has an explicit `[native code]` alternative and reports those frames as `null:null:null`. This makes the normalised form behave the same. `getOriginalPositionDetailsFor` returns an unresolved frame instead of passing a position `source-map` rejects, and the regex consumes a trailing `:0:0` after `[native code]` so the frame matches once rather than twice. Fixes: #966 Changelog: ``` - **[Fix]**: `metro-symbolicate` no longer fails on stack frames with no source position, such as `[native code]:0:0` in crash reporter output ``` ## Test plan ``` yarn jest packages/metro-symbolicate yarn flow check ``` New snapshot test over a crash-reporter-formatted trace containing `[native code]:0:0` frames, which fails on `main` with the `TypeError`.
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.
Summary
Assets outside
projectRootcurrently derive theirhttpServerLocationfrom a path relative toprojectRoot. This can produce..paths which escape/assets, and does not identify which configured watch folder owns the asset.This uses Metro's existing
[metro-watchFolders]/N/namespace for external asset URLs:getAssetsencode the path relative to the containing watch folder/assetsendpoint resolves the watch folder prefix before selecting platform and density variantsprojectRootretain their existing URLsKeeping these requests under
/assetspreserves Metro's platform-specific and density-aware asset resolution.Fixes #19
Fixes #290
Changelog: [Fix] Use indexed watch folder paths for assets outside
projectRootTest plan
Created a minimal project which imports an asset from a sibling watch folder:
index.jsimports the sibling asset:Started Metro from this checkout with
sharedconfigured as a watch folder:Requested an iOS bundle and inspected the generated asset metadata:
Metro normalises
projectRootas watch folder 0, so the configured sibling directory is watch folder 1.Requested the emitted asset path at 2x density for iOS:
The response body matches
tone@2x.ios.mp3, confirming that the indexed URL resolves through the sibling watch folder while retaining platform and density selection.Also ran:
All checks passed.