Handle Info.plist lookup in versioned frameworks

[shirakaba]

About

This PR fixes the following error I encountered when autolinking a framework built for macOS (which I brought up on Discord):

The error indicates that it was unable to find Info.plist at the root of the framework. Indeed, it should have been looking elsewhere.

Details

iOS frameworks conventionally have this "unversioned" structure, where the Info.plist is placed at the root of the framework:

NativeScript.framework
├── Headers
│   └── NativeScript.h
├── Info.plist
├── NativeScript
└── _CodeSignature
    └── CodeResources

macOS frameworks conventionally have a "versioned" structure, where the Info.plist is instead nested at Versions/Current/Info.plist:

NativeScript.framework
├── Headers -> Versions/Current/Headers
├── NativeScript -> Versions/Current/NativeScript
├── Resources -> Versions/Current/Resources
└── Versions
    ├── 0.1.0
    │   ├── Headers
    │   │   └── NativeScript.h
    │   ├── NativeScript
    │   ├── Resources
    │   │   └── Info.plist
    │   └── _CodeSignature
    │       └── CodeResources
    └── Current -> 0.1.0

This PR first checks for an Info.plist at the root, then falls back to checking at the nested path.

[cursor]

Bug: Missing Info.plist Causes Unhelpful Error

The readInfoPlist function tries to read the versioned Info.plist path without confirming it exists. If neither the unversioned nor versioned Info.plist is found, this leads to an unhelpful "file not found" error, which can complicate debugging framework structures.

 

[shirakaba]

This is intentionally consistent with the original behaviour. Happy to try-catch and rethrow with a cause if preferred. @kraenhansen

[kraenhansen]

A try-catch with a rethrow moving the error to cause could definitely make a failure easier to debug 👍

In the current code, it would however have to re-introduce the checking on error code to determine if it was indeed a missing file which caused the failure.

Another alternative (which I prefer) could be another helper to determineInfoPlistPath with two fs.existSync checks internally and finally throwing a meaningful error from that if none of the candidates paths exists. If we did that, reading the contents could be surrounded with a try-catch expecting a specific filepath to be readable.