[autolinking] Maintain hierarchical order when linking isolated modules (#24351)

# Why

My previous fix for isolated modules
(https://github.com/expo/expo/pull/23867) is not fully correct. The ol

[autolinking] Maintain hierarchical order when linking isolated modules (#24351)

# Why

My previous fix for isolated modules
(https://github.com/expo/expo/pull/23867) is not fully correct. The old
fix basically discovers _every dependency_ within the pnpm store folder.
- This works, but might also link modules that are unrelated to the Expo
project (e.g. when using monorepos).
- It also loses the hierarchical structure, e.g. nested dependencies
from `expo` (like `expo-application`) are added as being on the same
level as direct project dependencies.

# How

This new fix attempts to keep these nested dependencies hierarchy as
much as possible. Instead of looking up the pnpm store, it tries to
detect if isolated modules are used. If it's detected, it looks up every
individual "group of isolated modules" by expanding the `searchPaths`.

The detection is done by the following check:
- If the current "realpath" of the package being linked has a parent
`node_modules` folder ...
- ... and that `node_modules` folder is not "searched" yet (not added to
`searchPaths` yet) ...
- add this parent `node_modules` folder to the `searchPaths` to also
link dependencies in those folders

> ⚠️ This _**should**_ work, without checking on `.pnpm` store name,
since linked modules should never have a direct `node_modules` parent.
That only happens when using isolated modules.

# Test Plan

~~We probably need to add dedicated pnpm tests to autolinking, but for
now, it's manually testable with the following steps:~~

Added the two test cases below, as unit tests (lots of mocking).
Probably need to add e2e tests and use pnpm too. You can still test it
manually with the following steps:

- Create a basic Expo project anywhere
- `yarn create expo -t tabs ./test-pnpm-autolinking`
- `cd ./test-pnpm-autolinking`
- Create a dump of autolinking data, to compare it with pnpm
- `yarn expo-modules-autolinking resolve --platform android >
autolinking-yarn.json`
- Reinstall with pnpm
- `rm -rf node_modules yarn.lock`
- `pnpm install`
- Create a new dump of autolinking data, to compare it with yarn
- `node
<expo/expo>/packages/expo-modules-autolinking/bin/expo-modules-autolinking
resolve --platform android > autolinking-pnpm.json`
- Check if both `autolinking-yarn.json` and `autolinking-pnpm.json` is
identical

Then also check what happens if a different version of
`expo-application` is installed as project dependency. It should take
priority over the `expo > expo-application` version in both pnpm and
yarn autolinking.

I've used vscode launch for this to also check what exactly is going on
inside autolinking. For that, you'll need to add `.vscode/launch.json`
to your expo/expo repo, and update the paths. See snippet below:

<details><summary><code>.vscode/launch.json</code> file</summary>

```jsonc
{
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Expo Autolinking: resolve",
"program": "${workspaceFolder}/packages/expo-modules-autolinking/bin/expo-modules-autolinking",
"args": [
"resolve",
"--platform",
"android"
],
"console": "integratedTerminal",
// Update the path below to your Expo project installed with pnpm
"cwd": "/Users/cedric/Desktop/test-sdk-50/expo-pnpm"
}
]
}

```

</details>

# Checklist

<!--
Please check the appropriate items below if they apply to your diff.
This is required for changes to Expo modules.
-->

- [ ] Documentation is up to date to reflect these changes (eg:
https://docs.expo.dev and README.md).
- [ ] Conforms with the [Documentation Writing Style
Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
- [ ] This diff will work correctly for `npx expo prebuild` & EAS Build
(eg: updated a module plugin).

show more ...

[ios][autolinking] Fix missed react import patches (#23923)

Directives with leading or trailing whitespace on their line would not previously be patched

# Why

Noticed this in a project using a

[ios][autolinking] Fix missed react import patches (#23923)

Directives with leading or trailing whitespace on their line would not previously be patched

# Why

Noticed this in a project using a native module with `#import` blocks like this:

```objective-c
#if __has_include(<React/RCTBridgeModule.h>)
#import <React/RCTBridgeModule.h>
#elif __has_include("React/RCTBridgeModule.h")
#import "React/RCTBridgeModule.h"
#else
#import "RCTBridgeModule.h"
#endif
```

The very first clean build after `pod install` would work but all subsequent builds would fail with `Declaration of 'RCTBridgeModule' must be imported from module 'React.RCTBridge' before it is required`.

Eventually surmised that it was because this code block was only being half-patched by `expo_patch_react_imports!`. I think it was because the first build had no modulemap yet so went into one of the patched directives. Subsequent builds have a modulemap from the first build so ended up in the unpatched else instead?

# How

Updates the regexps to account for whitespace before or after the directives that are being looked for. Did it as a positive lookbehind and lookahead so existing indentation/trailing whitespace is left as-is once the patch is in place (seemed safer).

show more ...