Creation of .xcode.env.local points to a temp file for node when run using yarn

[lindboe]

Description

Who this affects: Anyone using a yarn alias to run pod install. This includes expo prebuild.

When using yarn to set up pods, Yarn generates temporary references to node and yarn executables that are not supposed to persist, but RN is capturing them and storing them in .xcode.env.local.

This will actually continue to work for most people, because the files in this temporary dir /var/folders/.../T should only be deleted after 3 days of not accessing them. Source: https://magnusviri.com/what-is-var-folders.html. I took a long weekend and my project broke 😄

Workaround: Delete .xcode.env.local if it exists, and then run bundle exec pod install directly, not using yarn, or run npx expo prebuild if you're using a recent expo project that uses prebuild. This should generate the .xcode.env.local file correctly.

Note: I'm not sure why .xcode.env.local is being generated automatically in the first place. My projects run fine without it present. This is especially painful with Expo CNG, because I can't choose to skip generation of this file, it means I have to avoid using yarn for prebuild, or add a config plugin just to manage .xcode.env.local.

Steps to reproduce

1. Have or create an RN app using yarn. Ensure there is no existing .xcode.env.local file:
   a. If this is a new project from template, say no to the cocoapods install when prompted. Run bundle install.
   b. If this was an existing project, delete the ios/.xcode.env.local file (it will be recreated by pod install).
2. Add a yarn alias for pod install in package.json:

   "scripts": {
      "pod-install": "cd ios && bundle exec pod install"
      ...
   },
   

3. Run the yarn alias: yarn pod-install. Note that ios/.xcode.env.local has been created, with a path to NODE_BINARY under /var/folders, like this: export NODE_BINARY=/var/folders/76/2f12v5nx7tq1vqbfptq455l00000gn/T/yarn--1709317581711-0.9959945438201141/node
4. Try to build the app with yarn ios. The build will work because the temporary alias to node still exists. However, once the temp file is deleted, builds will start failing.
5. Delete the temp file referenced in .xcode.env.local.

React Native Version

0.73.5.

Affected Platforms

Runtime - iOS, Build - MacOS

Output of npx react-native info

System:
  OS: macOS 14.3.1
  CPU: (8) arm64 Apple M1
  Memory: 73.97 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.9.0
    path: ~/.nvm/versions/node/v20.9.0/bin/node
  Yarn:
    version: 1.22.21
    path: ~/.nvm/versions/node/v20.9.0/bin/yarn
  npm:
    version: 10.1.0
    path: ~/.nvm/versions/node/v20.9.0/bin/npm
  Watchman:
    version: 2024.01.22.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods: Not Found
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.2
      - iOS 17.2
      - macOS 14.2
      - tvOS 17.2
      - visionOS 1.0
      - watchOS 10.2
  Android SDK: Not Found
IDEs:
  Android Studio: 2023.1 AI-231.9392.1.2311.11330709
  Xcode:
    version: 15.2/15C500b
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.10
    path: /Users/lizzi/.jenv/shims/javac
  Ruby:
    version: 2.6.10
    path: /Users/lizzi/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.5
    wanted: 0.73.5
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false

Stacktrace or Logs

The following build commands failed:
	PhaseScriptExecution [CP-User]\ [Hermes]\ Replace\ Hermes\ for\ the\ right\ configuration,\ if\ needed /Users/lizzi/Library/Developer/Xcode/DerivedData/TodoSharer-bpdgubyufiaiekcndqxujflhqusl/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/hermes-engine.build/Script-46EB2E0001C8A0.sh (in target 'hermes-engine' from project 'Pods')
(1 failure)

log file says this:
1099 Node found at: /var/folders/2d/_8p7fdvj1v13vkh7wyrbk14h0000gn/T/yarn--1707870956680-0.647996518200334/node
1100 /Users/lizzi/Library/Developer/Xcode/DerivedData/TodoSharer-bpdgubyufiaiekcndqxujflhqusl/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/hermes-engine.build/Scri     pt-46EB2E0001C8A0.sh: line 9: /var/folders/2d/_8p7fdvj1v13vkh7wyrbk14h0000gn/T/yarn--1707870956680-0.647996518200334/node: No such file or directory
1101 Command PhaseScriptExecution failed with a nonzero exit code

Reproducer

https://github.com/lindboe/temp-node-reproducer

Screenshots and Videos

No response

[github-actions]

⚠️	Add or Reformat Version Info
ℹ️	We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.70.2

[lindboe]

I discovered this and described the earlier issue #39903 (comment), backlinking for posterity

[tomoakley]

I have also come across this issue. Have found if you run the below command before you run expo prebuild or your yarn alias, it will generate the file with the path to the NODE_BINARY correctly, and the RN pod install process won't overwrite it.

  echo "export NODE_BINARY=$(printf '%q' "$(node -e 'console.log(process.execPath)')")" > ./ios/.xcode.env.local

so for example you can do

"pod-install": "./createXcodeEnvLocalFile.sh && cd ios && bundle exec pod install"

(you will probably need to do rm ./ios/.xcode.env.local first)

[cipolleschi]

This is super weird, we don't have anything in the react-native repo that can generate that file. Looking at this search.

What we do is to create the .xcode.env if it does not exists yet, but not the .local.

But this is unrelated from yarn. It does that for any project when pod install is used the first time.

Does it happens also in non-expo apps?

[tomoakley]

This is super weird, we don't have anything in the react-native repo that can generate that file. Looking at this search.

What we do is to create the .xcode.env if it does not exists yet, but not the .local.

But this is unrelated from yarn. It does that for any project when pod install is used the first time.

Does it happens also in non-expo apps?

Hi @cipolleschi, this PR added it in I believe #38879. The specific line in the main branch for react-native is here https://github.com/facebook/react-native/blob/main/packages/react-native/scripts/cocoapods/utils.rb#L230

I can confirm it also happens in non-expo apps.

(I assume this is it, sorry if not)

[cipolleschi]

Ah, yeah, 🤦
I haven't read properly the second part.

anyway... I think that it is safe to keep it, it has resolved so many issues that users opened because their environment was wrong.

I think that the proper solution is to generate a .xcode.env.local which is stable, i.e.: it is not using what is generated by yarn in the temporary folder.

I'll try to reproduce the issue and find a way to fix-forward.

[tomoakley]

Ah, yeah, 🤦 I haven't read properly the second part.

anyway... I think that it is safe to keep it, it has resolved so many issues that users opened because their environment was wrong.

I think that the proper solution is to generate a .xcode.env.local which is stable, i.e.: it is not using what is generated by yarn in the temporary folder.

I'll try to reproduce the issue and find a way to fix-forward.

Not sure if a combination of my solution would work, e.g something like:

if !file_manager.exist?("#{file_path}.local")
  node_binary = `printf '%q' "$(node -e 'console.log(process.execPath)')"`
  system("echo 'export NODE_BINARY=#{node_binary}' > #{file_path}.local")
end

I'm not particuarly well-versed in Ruby so not sure if running the inline executable node command would work. But process.execPath appears to be the correct path to the actual node executable, when running through yarn (on my machine and my colleagues machines, at least).

I would be happy to try and work on this and contribute back to RN. However I'm unsure how to test this.

[lorenz199x]

Hi,

I would like to share my experience on that file I have a project on react native and sometimes I encounter an error and my app wont start building or running on my emulator. I just delete the file and after that my app runs on the emulator. I'm just using this
"pods": "cd ios && rm -rf Podfile.lock && pod deintegrate && pod install && rm -rf .xcode.env.local", by running yarn pods or npm run pods every time I need to update my pod file. I hope it helps you guys. Thank you.

[scrungrth]

I'm using this in my package.json to workaround this issue

{
  "scripts": {
    "pods": "PATH=$(echo $PATH | sed 's/[^:]*://'); cd ios; pod install"
  }
}

[jrhe]

Another workaround for those using expo is to change your package.json as follows:

{
    ...
    "scripts": {
        ...
        "ios": "yarn expo prebuild; rm ios/.xcode.env.local; echo \"export NODE_BINARY=$(printf '%s' \"$(node -e 'console.log(process.execPath)')\")\" > ./ios/.xcode.env.local; yarn expo run:ios",
        ...
    }
    ...
}

[morganick]

Nice sleuthing on this, @lindboe! I've run into this on several projects now and kept forgetting how I solved it.

@cipolleschi what were some of the issues .xcode.env.local solved? I end up deleting it every time I see it 😅 I want to make sure I'm not shooting myself in the foot some other way.

[cipolleschi]

@morganick it's just to let a user override some settings locally, if needed. See it like:

• the .xcode.env is the general setup and the one run in CI.
• the .xcode.env.local is your local setup if you want to use some different versions, for example.

[raulburigo]

Is there a way to prevent this file to be automatically created?

[liamjones]

@raulburigo based on the current code, if you create the file but leave it empty it wouldn't be touched (note it's in the .gitignore). Or you could use patch-package to patch out these lines:

react-native/packages/react-native/scripts/cocoapods/utils.rb

Line 246 in 1cc1673

if !file_manager.exist?("#{file_path}.local")

[deggertsen]

For now, we're just adding && rm ./ios/.xcode.env.local to the end of all our scripts. It would be really nice to have this fixed though. It does seem to be related to using NVM. Might be able to use an alternative to fix the issue?

[aldiand]

this script help me,
for eas build, use this script
"eas-build-post-install": "rm ./ios/.xcode.env.local",

For now, we're just adding && rm ./ios/.xcode.env.local to the end of all our scripts. It would be really nice to have this fixed though. It does seem to be related to using NVM. Might be able to use an alternative to fix the issue?

[cipolleschi]

I just landed a fix that should resolve this issue.
I tried to change the default shell from bash to zsh to see if it would pickup the env var in that way, but it doesn't. Xcode really creates a sort of new env when it runs.

The solution I implemented is basically to list all the possible node and to discard the temporary ones. So we should always have a stable value for the node_binary.

[matthieugicquel]

I just spent some time debugging this before finding this PR, here’s what I found along the way in case it’s useful:

@Kudo from Expo used a different way to get the "right node": node --print "process.argv[0]";

He fixed the same issue a while ago for expo projects.

But #38879 introduced generation of .xcode.env.local in react-native core, and it runs before the one in expo, so the “already fixed” code in expo never runs.

[rodperottoni]

I recently bumped my application to React Native 0.75.3 and this issue seems to still be around. The reason why is .xcode.env.local is generated with a temporary node that lives under /private/var rather than /var, and thus the latest changes in react-native/scripts/cocoapods/utils.rb don't seem to have any effect:

node_binary = `type -a node`.split("\n").map { |path|
    path.gsub!("node is ", "")
}.select { |b|
    !b.start_with?("/var") // This doesn't handle `/private/var`!
}

Pretty frustrating to have to have a patch around this :/

[cipolleschi]

@rodperottoni
I see, probably your setup is slightly different than mine and I could not test that. Thanks for reporting.
I'll try to prepare a fix for that.

If you change the line

-!b.start_with?("/var")
+!b.start_with?("/private/var")

does it fixes it for you?

[morganick]

@cipolleschi can the generation of the .xcode.env.local be opt-in instead of opt-out? Different members of our team continue to hit their head on this on various projects. Eventually, we remember this file exists and have to go update it.

Was the problem this file tries to solve so prevalent that it necessitates it being generated for every project?

[lindboe]

I will second @morganick and re-iterate that I think that storing a path to the node executable in .xcode.env.local interferes with what most version manager tools are trying to accomplish: dynamic resolution of the tool at runtime.

I think we should be dynamically resolving the node executable each time, and maybe ONLY if we fail to find one, we can fall back to a cached value for the path to it if we must.

That said, I'm still not convinced storing the path to the executable is necessary.

If the core issue here is making sure node is resolved correctly when scripts are run by the XCode GUI, I personally solve this by configuring nvm in .zshenv, which allows xcode's non-interactive shell to use it. I mentioned this as part of this comment, and noted it's part of the docs already.

There is a caveat here, which is that MacOS has a tool called path_helper that can re-order the path variable during the zprofile step, so you can't only run your setup in .zshenv, if you're configuring tools that MacOS installs by default, like ruby, vim, or git. In that case you may have to also reconfigure path again in .zshrc to make sure you get your tools first in the path. This has not been problem for node for me, though.

[douglasjunior]

I will second @morganick and re-iterate that I think that storing a path to the node executable in .xcode.env.local interferes with what most version manager tools are trying to accomplish: dynamic resolution of the tool at runtime.

The problem is that this has never worked properly; we must run a ln -s $(which node) /usr/local/bin/node to fix the issue.

To make matters worse, the variations of alternatives to “nvm” are numerous, and more keep appearing daily.

[lindboe]

@douglasjunior I'm not fully following your response, would you mind explaining more?

When do you need to run ln -s to make things work? What breaks without it? This is not something I've ever needed to do.

My explanation of what I do to make version managers work in XCode should work for any version manager and is up to the developer who installed the version manager to configure.

[douglasjunior]

Hi @lindboe!

Since 2017, when I started working with React Native, whether on Mac (Android/iOS) or Linux (Android), we've encountered this kind of issue whenever we use NVM or similar.

• GH: https://github.com/facebook/react-native/issues?q=is%3Aissue+%22cannot+run+program%22+node
• SO: https://stackoverflow.com/search?q=%5Breact-native%5D+cannot+run+program+node

Even after following 100% of the NVM setup instructions and configuring either .bash_profile or .zshrc, someone would always run into errors like Cannot run program “node”.

I 100% agree with you when you say "is up to the developer who installed the version manager to configure", but my question is: Is it trivial? Only following the version manager docs is enough? Or do we still need to do some tricks to work with React Native?

My concern is that, from what I observe, the maintainers of version managers never think about React Native; we are an exception.

[lindboe]

@douglasjunior Have you tried what I suggested above about configuring version managers in .zshenv as well?

That file is sourced in non-interactive shells like the one XCode uses when running scripts.

Otherwise, I'd interested in knowing exactly where this fails. It's difficult for me to know if my proposed solution covers your use case or not if I don't know exactly when you run into errors.

[douglasjunior]

@lindboe I have never tried the .zshenv, this is the first time that I heard about .zshenv. What we normally do is just follow the nvm docs and put the envs in the .zshrc and .bash_profile.

In the last RN versions this problem is gone with the .xcode.env, now when we run the pod install for the first time the .xcode.env.local is created and it just works.

The only change we made recently was in the .xcode.env to be:

export NODE_BINARY=$(which node)

[cipolleschi]

Some context might help with the decision we make.

The generation of .xcode.env.local helps all the new users that starts working with React Native for the first time. Those are the main target of most of our changes: we want to provide them with the best and most seamless experience, because they are the ones that we risk to lose the most if the experience is not neat.

Imagine if we do not generate the xcode.env.local. A new user that knows nothing about react native and a little about iOS will follow the tutorial and will try to build the app, to see it failing with a weird error that ask to add a line in an .xcode.env file.

It opens the file and sees that it is already properly configured. What's now? They will start searching online for a solution and they might spend hours before finding it.

The problem is that this has never worked properly; we must run a ln -s $(which node) /usr/local/bin/node to fix the issue.

@douglasjunior solution is the best one. The only problem, ln -s in /usr/local needs to be run with sudo. There is no way to put this call in the pod install step, as asking for a password in that step will:

1. make it not automatable (all CI flows will break)
2. create distrust in users (Why do you need my password? Are you actually going to use it for what you say you will use it?)

If the core issue here is making sure node is resolved correctly when scripts are run by the XCode GUI, I personally solve this by configuring nvm in .zshenv, which allows xcode's non-interactive shell to use it. I mentioned this as part of #43333 (comment), and noted it's part of the docs already.

@lindboe This will be an extra configuration step, which is exactly what we are trying to avoid. I also experimented in making zsh the default shell for Xcode scripts, but this did not solve the issue.

can the generation of the .xcode.env.local be opt-in instead of opt-out?

@morganick Sadly, for the first explanation of this post, no. I'd rather:

1. fix this properly
   or
2. create a system for which you can specify in the Podfile to opt out from it. So if there are teams that don't need the automatic creation of the xcode.env.local they can opt out. (Actually, it is already like this... if you create your own .xcode.env.local, we would not rewrite it).

[lindboe]

The generation of .xcode.env.local helps all the new users that starts working with React Native for the first time. Those are the main target of most of our changes: we want to provide them with the best and most seamless experience, because they are the ones that we risk to lose the most if the experience is not neat.

I appreciate that perspective a lot! Making a great experience for new users is important.

There's two reasons why I think that may not support this solution, though:

1. The React Native getting started guide has always required people to install tools and do some setup before getting started. That configuration typically involves shell initialization files anyways. (I see that the guide now says "Setting up your environment is not required if you're using a Framework", but I was trying to scope this discussion to just what we'd want if bringing your own framework. If relevant, Expo or other frameworks could provide similar instruction or auto-configure it.)
2. If new users are unsure how to configure their own tools here, they're much less likely to be using a version manager. If they're not using a version manager, their installed version of node would likely work by default in XCode.

I think this could also be more cleanly addressed for new users by having scripts link to documentation to how to solve this problem if node fails to be found.

I also experimented in making zsh the default shell for Xcode scripts, but this did not solve the issue.

I want to clarify here: zsh is supposed to be the default shell for MacOS now, so that's why I was referring to zsh. I would've expected XCode to already be using zsh.

If we discuss this further, I'd be curious to hear what went wrong, since this has worked for me.

Supporting bash is a little more complicated, because for non-interactive, non-login shells, which XCode appeared to be using from my testing, you have to set BASH_ENV to a script that will do the configuration you want. Less convention available here, but still doable when the script is user-configured.

Teams that don't need the automatic creation of the xcode.env.local they can opt out. (Actually, it is already like this... if you create your own .xcode.env.local, we would not rewrite it).

This is a workaround I can live with, but is not ideal, IMO. It still means that version managers will not work as expected long-term, since we can't rely on the correct version of node being used, unless teams know to override this.

[kevinvangelder]

@douglasjunior in my 9-10 years of doing RN development, I don't recall ever seeing that Cannot run program "node" error and, as far as I know, none very few of the Infinite Red developers have either. On the other hand, many of us have run into an invalid path being written to .xcode.env.local prohibiting builds. If this can't be switched to being opt-in, something needs to be done to check that the path is valid and that a working version of node exists at that path before the file is written.

EDIT: This isn't to say that the error can not or does not occur, rather that it may not occur as frequently as it appears some folks believe. Therefore, forcing everyone to use the same solution, even if they've never experienced the problem, and the solution causes other issues for them, is not great.

[cipolleschi]

I want to clarify here: zsh is supposed to be the default shell for MacOS now, so that's why I was referring to zsh. I would've expected XCode to already be using zsh.

Sadly, it is not.

in my 9-10 years of doing RN development, I don't recall ever seeing that Cannot run program "node" error and, as far as I know, none very few of the Infinite Red developers have either.

The infrastructure changed a bit in the last 2-3 years. Before, we used to have an unmaintainable file called find-node.sh that was trying to exhaustively list all the node manager with all the possible configurations to get the right path. We decided, for our sanity, to remove that file and we started seeing people blocked because of the Cannot run program "node" error.

That's why we introduced the .xcode.env file. Since then, the number of people failing to run React Native projects dramatically reduced, so I still think that it is valuable.

The point here is to try and find the right trade-off to balance the experience of so many people.

I believe that providing the right .xcode.env.local is the best solution: no upfront configuration, that is always a cost, and a good experience.

Something we can do is try to improve the messaging even further: I can fix the issue and then, if more node are found, prompt a visible warning in Pod Install pointing the user to a possible source of issue so that they can fix it right away.

I believe that this is the best alternative we have to balance a good experience for new users and help more seasoned users to set up their environment properly.