Unpin @expo/plist and update it (post-merge follow-up to pnpm migration)

[kraenhansen]

Context

As part of the pnpm migration (#381), regenerating the lockfile floated @expo/plist from 0.4.7 (the version main's package-lock.json happened to hold) up to 0.4.9. In 0.4.9, plist.parse() returns a null-prototype object, which makes the strict assert.deepEqual in packages/host/src/node/cli/apple.test.ts ("should read Info.plist contents, plus extra keys not in schema") fail on the prototype mismatch.

To keep the migration behaviour-neutral, @expo/plist was pinned to an exact 0.4.7 in packages/host/package.json:

-    "@expo/plist": "^0.4.7",
+    "@expo/plist": "0.4.7",

The null prototype only affects the test's strict equality — runtime property access on the parsed object is unaffected — so this is a test-only concern, not a functional regression.

Follow-up

Once the pnpm migration is merged, revisit this pin:

• Update @expo/plist to the latest 0.4.x (or newer) and restore a caret range (^) in packages/host/package.json.
• Make readInfoPlist / apple.test.ts robust to the null-prototype return so the test no longer depends on the parser's object prototype. Options:
  • normalise the parsed value before asserting (e.g. { ...contents } or structuredClone), or
  • have readAndParsePlist return a plain object, or
  • use a non-strict deep-equal for this assertion.
• Confirm the macOS Unit tests job passes with the unpinned version.

References

• PR: chore: migrate from npm workspaces to pnpm #381
• File: packages/host/package.json (@expo/plist pin)
• Test: packages/host/src/node/cli/apple.test.ts