[autolinking] Fix node resolution error when executed from scripts

[Kudo]

Why

fix https://github.com/expo/expo/pull/18330#issuecomment-1208645614

How

when executed from package.json scripts, the node from command -v node is actually a wrapper to temp file, e.g. /var/folders/yw/6bx918xn4671rggfcdxz7fph0000gn/T/yarn--1660058355887-0.20052152174853344/node

#!/bin/sh

exec "/Users/kudo/.volta/tools/image/node/16.16.0/bin/node" "$@"

the temp wrapper file may be purged soon after prebuild completed.

the pr changes the command -v node to node --print "process.argv[0]" when generating the .xcode.env.local content. it should be the final node path. even though it's slightly different for my setup, e.g. volta: /Users/kudo/.volta/bin/volta -> /Users/kudo/.volta/tools/image/node/16.16.0/bin/node where it was originally pointed to volta wrapper path and now to final node executable. that should be fine for pointing to final node executable path though.

Test Plan

yarn create expo-app -t blank@sdk-46 sdk46
# add `"prebuild": "npx expo prebuild -p ios --clean"` to package.json *scripts* field
yarn prebuild
# verify the content of .xcode.env.local

Checklist

• [x] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md).
• [x] Conforms with the Documentation Writing Style Guide
• [x] This diff will work correctly for expo prebuild & EAS Build (eg: updated a module plugin).

[ide]

it's slightly different for my setup, e.g. volta: /Users/kudo/.volta/bin/volta -> /Users/kudo/.volta/tools/image/node/16.16.0/bin/node where it was originally pointed to volta wrapper path and now to final node executable. that should be fine for pointing to final node executable path though.

I could see this changing breaking the behavior of Volta specifically. For example, if a project's package.json contains "volta": { "node": "16.6.0" }, the developer generates .xcode.env.local, and then package.json is updated to contain "volta": { "node": "18.7.0" }, Xcode will still use Node 16.6.0.

IMO this is not a blocking issue because we tell the developer the contents of .xcode.env.local and they can change it themselves, but it would a better developer experience to link to Volta's node shim. I have two suggestions:

1. Merge this commit the way it is. It is consistent and simple.
2. Use which -a node and find the first path that is not in $TMPDIR. Fall back to node --print ... if necessary.

[Kudo]

I could see this changing breaking the behavior of Volta specifically. For example, if a project's package.json contains "volta": { "node": "16.6.0" }, the developer generates .xcode.env.local, and then package.json is updated to contain "volta": { "node": "18.7.0" }, Xcode will still use Node 16.6.0.

we talked about this before: https://github.com/expo/expo/pull/18330#discussion_r928509477. nvm would have similar issue because nvm doesn't have a wrapper like volta's node shim. when user changes the default node version, the old .xcode.env.local may still point to the old node version.

2. Use which -a node and find the first path that is not in $TMPDIR. Fall back to node --print ... if necessary.

for my case, which -a node executed from package.json scripts would return more node paths:

/var/folders/yw/6bx918xn4671rggfcdxz7fph0000gn/T/yarn--1660149373429-0.37021388096968333/node
/Users/kudo/.volta/tools/image/node/16.16.0/bin/node
/Users/kudo/.volta/bin/node
/usr/local/bin/node
/Users/kudo/.volta/bin/node

the first path that is not in $TMPDIR is exactly the same with node --print ...

[ide]

the first path that is not in $TMPDIR is exactly the same with node --print ...

That's too bad. Let's just use what you have in this PR then.

[Kudo]

thanks! i'm going to land this fix.

[hirbod]

After trying this fix, it now generated a correct path for me @Kudo, but XCode still failed to build the project. Told me "command node not found" and "command react-native not found".

The final fix for me was

sudo ln -s "$(which node)" /usr/local/bin/node

[Kudo]

@hirbod oh no. could you share the detailed build log? i would like to know which build phase scripts caused the problem. thanks!