Skip to content

Two test gaps: unverified prebuild Info.plist and a missing .node fixture in the Babel plugin tests #424

Description

@kraenhansen

Two TODOs marking tests that assert less than they appear to.

verify-prebuilds skips the Info.plist it just found

The verifier walks each framework in the XCFramework and continues past Info.plist without reading it. That file is written by writeFrameworkInfoPlist in packages/host/src/node/prebuilds/apple.ts from the library name and bundle identifier, and a wrong CFBundleExecutable or CFBundleIdentifier is exactly the kind of failure that passes every build step and then fails at load time on device. Parsing it and asserting the executable name matches the library, and the identifier matches what was requested, is a handful of lines given @expo/plist is already a dependency.

"does not touch required JS files" doesn't prove what it claims

The test fixture in packages/host/src/node/babel-plugin/plugin.test.ts has my-addon.js and asserts the plugin does not emit requireNodeAddon. But with no my-addon.node in the fixture there is nothing for the plugin to have found in the first place, so the assertion passes for the wrong reason and would keep passing even if the precedence between a .js and a sibling addon were broken. Adding a ./my-addon.node alongside it, as the TODO says, is what makes the test meaningful: with both present, require('./my-addon') must still resolve to the JS file. Completing the fixture also exposes a real bug: isNodeApiModule rewrites the require to requireNodeAddon(...) even when my-addon.js sits beside my-addon.node, so the fix needs to preserve Node's JS/JSON resolution before addon rewriting.

Status

Both gaps (the Info.plist verification and the .js/.node precedence fix with its fixture) are addressed by #426, which is open, approved, mergeable and green in CI. Both TODOs are still present on main until it lands, and no other implementation is in flight.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    AutomatableAn issue we expect to be fixed using automation.good first issueGood for newcomers

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions