Summary:
Pull Request resolved: #963

D5380795 (6 years ago) introduced a workaround for a Babel re-entrancy bug reported by React Native users in facebook/react-native#14530.

Since babel/babel#7588 (Babel 7.0), this bug was fixed upstream - it's now effectively a no-op to register Babel twice. The old workaround gets in the way of cleanly "unregistering" Babel because it pushes two hooks onto the `pirates` stack, and possibly has a slight perf impact.

Changelog: Internal

Reviewed By: huntie

Differential Revision: D44627126

fbshipit-source-id: b7971af85c5d9ad9e71b53409170c7040f07217d

Summary:
Changelog:
 * **[Experimental]**: Pass full path and query params to `asyncRequire` for lazy bundles.

Moves the responsibility for setting query params on lazy bundle requests from the runtime to the serializer. This is a breaking change to any `asyncRequire` implementations currently relying on the experimental second parameter.

See the [lazy bundling RFC](react-native-community/discussions-and-proposals#605) for more context. Note that replacing `asyncRequire` using `asyncRequireModulePath` will itself be deprecated with the introduction of the `__loadBundleAsync` runtime hook.

Reviewed By: robhogan

Differential Revision: D43597023

fbshipit-source-id: 8943cfee04abd5f7e23b5cbb2047d401c728fe14

Summary:
Metro's `require` polyfill is expected to print require cycle warnings, and when testing cycle scenarios this spams the Jest output (except in the one case where we explicitly mock `console.warn` to check the warning).

This diff lifts the `console.warn` spy up so as to silence it.

Changelog: Internal

Reviewed By: jacdebug

Differential Revision: D44505719

fbshipit-source-id: 9ca845aa218d49896dcc2ec4723b403513302d80

Summary:
This trims some of the Babel transformations `metro-babel-register` currently applies for *Node JS* targets (this is unrelated to React Native's targets).

It's non-breaking as we already have an `engines` constraint of Node >= 16.0, and that version already supports the syntax concerned.

Node has supported:
 - Nullish coalescing (`babel/plugin-proposal-nullish-coalescing-operator`) since [14.5.0](https://node.green/#ES2020-features--nullish-coalescing-operator-----)
 - Optional chaining (`babel/plugin-proposal-optional-chaining`) since [14.5.0](https://node.green/#ES2020-features-optional-chaining-operator-----)
 - Non-private class properties (`babel/plugin-syntax-class-properties`) since [14.21.3](https://node.green/#ES2022-features-instance-class-fields)

Changelog: Internal

Reviewed By: jacdebug

Differential Revision: D44679156

fbshipit-source-id: 2af2b3cc220fd5e34b6a4c0d9528bed5561f5468

Summary:
Fixes an awkward bug where, while attempting package resolution against candidate `node_modules` paths, paths which don't exist are short-circuited to the parent package if present. Because Package Exports resolution has the side-effect of logging a warning for an invalid package path (`PackagePathNotExportedError`), repeat `resolvePackage` calls under this scenario (to apparent subpaths including `/node_modules/`) would log incorrect warnings to the terminal.

More specifically, this is because `context.getPackageForModule` uses a different resolution strategy to the top-level `resolve` function (originating from the `redirectModulePath` design). This produces a mismatch where we may eagerly locate a parent package. Independently, we should address this disparity in future.

Does not affect [`"browser"` spec](https://github.com/defunctzombie/package-browser-field-spec) / `mainFields` resolution, since the `redirectModulePath` approach bypasses the above `node_modules` lookup strategy in the simple case.

Changelog: **[Experimental]** Fix bug where Package Exports warnings may have been logged for nested `node_modules` path candidates

Reviewed By: motiz88

Differential Revision: D44149246

fbshipit-source-id: 43df6885e712a93f9d07e8fb8e2e36132a766fc8

Summary:
X-link: facebook/react-native#36819

Pull Request resolved: #964

This diff creates a new hook to the Metro symbolicator. `customizeStack` aims to provide a whole stack modification hook on the output of the `/symbolicate` endpoint.

The purpose of this hook is to be able to apply callsite-based modifications to the stack trace. One such example is user-facing frame skipping APIs like FBLogger internally.

Consider the following API:

```
  FBLogger('my_project')
    .blameToPreviousFile()
    .mustfix(
      'This error should refer to the callsite of this method',
    );
```

In this particular case, we'd want to skip all frames from the top that come from the same source file. To do that, we need knowledge of the entire symbolicated stack, neither a hook before symbolication nor an implementation in `symbolicator.customizeFrame` are sufficient to be able to apply this logic.

This diff creates the new hook, which allows for mutations of the entire symbolicated stack via a `symbolicator.customizeStack` hook. The default implementation of this simply returns the same stack, but it can be wrapped similar to `symbolicator.customizeFrame`.

To actually have information for this hook to act on, I've created the possibility to send additional data to the metro `/symbolicate` endpoint via an `extraData` object. This mirrors the `extraData` from https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/Core/NativeExceptionsManager.js#L33, and I've wired up LogBox to send that object along with the symbolicate call.

Changelog:
[General][Added] - Added customizeStack hook to Metro's `/symbolicate` endpoint to allow custom frame skipping logic on a stack level.

Reviewed By: motiz88

Differential Revision: D44257733

fbshipit-source-id: 05cd57f5917a1e97b0520e772692ce64029fbf8a

Summary: Add Flow comment coverage to `metro-babel-register`

Reviewed By: huntie

Differential Revision: D44706998

fbshipit-source-id: 22a111bec1e4af563d065ac7785a252cc8e6b161

Summary:
`react-native-community/cli-plugin-metro` has a dependency on `mergeConfig`, `loadConfig` and `resolveConfig` from `metro-config`, here:

https://github.com/react-native-community/cli/blob/v12.0.0-alpha.2/packages/cli-plugin-metro/src/tools/loadMetroConfig.ts#L3-L9

Otherwise, `cli-plugin-metro` only has build-time dependencies on `metro-config`. By exporting `resolveConfig` in addition to the other two (which we already re-export), we can remove the `metro-config` runtime dependency and use `metro` instead.

That's a step closer to making `metro` a `peerDependency` of `cli-plugin-metro`, with version dictated by the host project's dependency, ultimately decoupling Metro from the CLI.

Changelog:
```
* **[Feature]** Re-export `metro-config`'s `resolveConfig` from `metro`.
```

Reviewed By: hoxyq

Differential Revision: D44870484

fbshipit-source-id: c38175cac5904b0b9540bab6b4c8e70d957d378e

Summary:
Following D44870484 with the goal of decoupling RN CLI from an exact Metro version - `react-native-community/cli` wraps `Terminal` for its `reporter` implementation when starting Metro server, here:

https://github.com/react-native-community/cli/blob/v12.0.0-alpha.2/packages/cli-plugin-metro/src/commands/start/runServer.ts#L45-L47

This is the only dependency `cli-plugin-metro` has on `metro-core` - by re-exporting it from `metro` we can [remove a dependency](https://github.com/react-native-community/cli/blob/v12.0.0-alpha.2/packages/cli-plugin-metro/package.json#L16) from the CLI.

Changelog:
```
* **[Feature]** Re-export `metro-config`'s `resolveConfig` from `metro`.
```

Reviewed By: hoxyq

Differential Revision: D44870838

fbshipit-source-id: 94baf444f495439e45ff77340601afd6900bbc3f

Summary:
Previously, the aliases we had configured for `metro/src/` imports were misaligned.

https://pxl.cl/2Clhj

Changelog: [Internal]

Reviewed By: robhogan

Differential Revision: D44921893

fbshipit-source-id: b86882f6a4e6c5125ba1901a1216d1c91884a761

…ependency

Summary:
Remove a dependency on the TypeScript types for `babel/code-frame` by inlining the definition we need.

This also tightens it up (this is an output type, so that's non-breaking) to match the (enforced) Flow type, which is much more strict: https://github.com/facebook/metro/blob/v0.76.1/flow-typed/babel.js.flow#L33-L36

For reference, the Babel type previously imported was this:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/a785fc80eb9e588cdef1e4c008225e167a8d925f/types/babel__code-frame/index.d.ts#L7-L10

Changelog:
```
* **[Types]** Remove dependency on `types/babel__code-frame`
```

Reviewed By: huntie

Differential Revision: D44928583

fbshipit-source-id: 7b50e111d2f62da0a7d0bc6365923fc33bf99e50

…s` dependency

Summary:
Define the minimal interface we need for `runServer`'s `websocketEndpoints` option - the expectations is a `Websocket` implementation will be supplied, but since there are several of those for Node JS (`ws`, `websocket`) that broadly aim to implement the same web specification, I think it's best to be unopinionated in the type we require and just specify the parts of the interface Metro needs - this has been stable for some time.

The starting point for this type is from `types/ws`, here:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/a785fc80eb9e588cdef1e4c008225e167a8d925f/types/ws/index.d.ts#L349-L354

I've mirrored this change in Flow to ensure that our source is checked against the same rules we're exposing in TS.

Changelog:
```
* **[Types]** Remove dependency on `types/ws`
```

Reviewed By: huntie

Differential Revision: D44930635

fbshipit-source-id: b5b27fe4875aa39bf74d82b62463a9bd7c3846b9

Summary:
Follow-up to D44509764. `metro-source-map`'s entry point is `src/source-map.js`.

Changelog: **[Types]** Fix TypeScript types entry point for metro-source-map

Reviewed By: jacdebug

Differential Revision: D44953195

fbshipit-source-id: 82aafbe443f51ae1f1f2dffe7d4ce4ea206fa00f

Summary:
`.npmignore` follows `.gitignore` syntax (ref: [npm docs](https://docs.npmjs.com/cli/v9/using-npm/developers?v=true#keeping-files-out-of-your-package)).

In this syntax, `build` would match any file or directory called `build` anywhere in the source tree, because it doesn't contain a `/`. The intention of this line is only to ignore the package root level `build` *directory*, and the syntax `/build/` is the correct way to do that. Similarly for `src.real`.

OTOH, the trailing `**` in `**/__tests__/**` serves no purpose.

This diff fixes entries to match our intention, ahead of adding an ignore entry `/types`.

Reviewed By: huntie

Differential Revision: D44954076

fbshipit-source-id: 489de3f3f7fd0d4e372c5877feea3fd1577c75fa

Summary:
We keep the canonical versions of `.d.ts` files under `/types` in each package. To enable config-free resolution, we copy these alongside their respective source files under `/src` as part of the build step (via a temporary `/build` directory).

However, because `/types` are not ignored, we end up publishing two copies of every definition - one under `/types` and one under `/src`. The latter isn't needed in distributed builds, and may lead to confusion as well as just being unnecessary package weight.

This adds `/types/` to `.npmignore` so that this directory isn't published to NPM.

Changelog: [Internal]

Reviewed By: jacdebug

Differential Revision: D44954387

fbshipit-source-id: 0ea1e5199561f0211f2f15422a5757eb02dc697b

Summary:
Fixes #965.

**Cause**: The implementation of `context.getPackageForModule(modulePath: string)` attempts to locate a `package.json` file starting with `parsedPath.dir` — however this clobbers the path basename when `modulePath` is initially the package directory.

e.g. for the path `/root/node_modules/ipld/dag-cbor` (a package root):

- `/root/node_modules/ipld/dag-cbor/package.json` **exists**.
- `getPackageForModule('/root/node_modules/ipld/dag-cbor')` begins traversal, **incorrectly**, from `/root/node_modules/ipld`.

https://pxl.cl/2Cb1T

**Why this didn't matter until now**

- This was previously inconsequential for `mainFields` (`"browser"` field spec), since redirections ***only*** support subpaths. (`"browser"` does not describe/permit a `"."` subpath, but instead a redirection of a *file path*, e.g. `"./index.js"`.)
https://github.com/defunctzombie/package-browser-field-spec#replace-specific-files---advanced

- On fall through from `mainFields` subpath resolution (implemented via `context.redirectModulePath` and not sharing the regular `nodeModulesPath` iteration loop), `resolveModulePath` will attempt `./package.json` to call [`getPackageEntryPoint`](https://github.com/facebook/metro/blob/d0b8ea57749d081f66c62ad4a4863caff62aa1d4/packages/metro-resolver/src/PackageResolve.js#L23).

Note: In tests, this behaviour was already (necessarily) added in D43055160, but did not line up!:
https://github.com/facebook/metro/blob/d0b8ea57749d081f66c62ad4a4863caff62aa1d4/packages/metro-resolver/src/__tests__/utils.js#L102

Changelog: **[Experimental]** Fix `package.json` discovery against root package specifiers for Package Exports

(⬆️ Would previously fall-through to file-based resolution.)

Reviewed By: robhogan

Differential Revision: D44877146

fbshipit-source-id: bb02d81b9e7d2ef71846d492cfbc38c85a4bf98b

Summary:
We've realised that the implementation of this API ([`DependencyGraph._getClosestPackage`](https://github.com/facebook/metro/blob/61a30b7fc2075cf53f87ae8ad7b7423d204ef670/packages/metro/src/node-haste/DependencyGraph.js#L152-L164)) is mismatched with the rest of the resolver, which will additionally consider options such as `context.nodeModulesPaths` and `context.extraNodeModules`. Therefore we're marking this API as deprecated, to discourage new features from relying on it.

We will not be physically removing this API for a long time yet! (`"browser"` field resolution relies on this.)

Changelog: [Internal]

Reviewed By: robhogan

Differential Revision: D44706188

fbshipit-source-id: c3c7c478c6f859e56a95c72d9d209ec137c8aa33

Summary: Changelog: None

Reviewed By: motiz88

Differential Revision: D44954921

fbshipit-source-id: 2a07c69d554ad670eab7e3f0dce6296d9465ff13

Summary: Publish version 0.76.2

Reviewed By: robhogan, huntie

Differential Revision: D44972328

fbshipit-source-id: 357e2ab7552a09f5053eaeb1ce0b05744de2b4b3