[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 ...

[lint] Upgrade to Prettier v3, typescript-eslint to v6 (#23544)

Why
---
Prettier 3 is out. Add support for it with this linter config.

**Note for reviewer:** the first commit is the one with th

[lint] Upgrade to Prettier v3, typescript-eslint to v6 (#23544)

Why
---
Prettier 3 is out. Add support for it with this linter config.

**Note for reviewer:** the first commit is the one with the actual
changes. The rest of this PR are changes to get the linter passing
(mostly autofix).

How
---
Update eslint-config-prettier and eslint-plugin-prettier. To address
deprecation warnings, also update typescript-eslint/parser and
typescript-eslint/eslint-plugin.
Because of an update to typescript-eslint/parser, we need to suppress
deprecation warnings (documented in a comment).

Regenerated test snapshots. Due to the upgraded dependencies, typecasts
and optional chaining are now auto-fixable by lint. This converts
warnings into autofixes.

Test Plan
---
`yarn test` in the linter config. Run `expotools check --all --fix-lint
--no-build --no-test --no-uniformity-check` to try this config on the
whole repo.

---------

Co-authored-by: Expo Bot <[email protected]>

show more ...

[autolinking] Add support for pnpm isolated modules (#23867)

# Why

This updates auto-linking to support discovering packages installed with
`pnpm`, using the default "isolated module" behavior.

[autolinking] Add support for pnpm isolated modules (#23867)

# Why

This updates auto-linking to support discovering packages installed with
`pnpm`, using the default "isolated module" behavior.

# How

- Updated pattern matching to include
`node_modules/.pnpm/<pkg>@<version>/node_modules/<pkg>` paths

We could also filter out some of the symlinks with [something similar to
this](https://github.com/mrmlnc/fast-glob/issues/302#issuecomment-869200625).
But the current duplication handling seems to be able to handle
potential duplicates.

# Test Plan

This fix is extracted from my pnpm tests to try get pnpm working,
without any workarounds. See this repo for more info:
https://github.com/byCedric/expo-pnpm-tests/tree/main

# 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).

---------

Co-authored-by: Expo Bot <[email protected]>

show more ...