Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51836
Currently, `community-cli-plugin` loads the user config and then overrides parts of it - specifically `resolver.resolveRequest` and `serializer.getModulesRunBeforeMainModule`, making it impossible for a user to modify this config.
Instead, treat the CLI's resolver and serializer customisations as "Framework defaults", layered on top of `react-native/metro-config` defaults but beneath a user's `metro.config.js`.
This allows the user to obtain (via `react-native/metro-config`'s `getDefaultConfig`) and extend or override them, if they need to.
This is technically breaking because users who currently have a custom `resolveRequest` or `getModulesRunBeforeMainModule` in their `metro.config.js` will have that config respected from this change, whereas currently they won't have any effect.
Changelog:
[General][Breaking] Community CLI users: user-defined `resolver.resolveRequest` and `serializer.getModulesRunBeforeMainModule` Metro config now takes precedence over CLI defaults
Reviewed By: huntie
Differential Revision: D74811395
fbshipit-source-id: c250caf798fdaedb0822bea3d6e65c0c3ae4d691
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50494
Changelog: [internal]
Removes the dependency on the `event-target-shim` npm package now that we're using a custom implementation within `react-native`.
Reviewed By: yungsters
Differential Revision: D67828636
fbshipit-source-id: 8727f8caa2bd4badd7162eb7b993dcc768e74b85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49780
Now that we're using a minimum Metro version of 0.81.3, Metro will dynamically assert `import` or `require` based on the style of the import at source.
Asserting both is likely to cause issues with `babel/runtime` and potentially other packages - see https://github.com/facebook/metro/pull/1447.
Changelog:
[Internal] metro-config: Assert import/require dynamically when using `unstable_enablePackageExports` with Metro.
Reviewed By: hoxyq
Differential Revision: D70473577
fbshipit-source-id: b3e6fbd78e2b6fc0f9a16ec3db2c19698848e6d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49102
Moves this script one level up. In the next diff, will be used to support execution of scripts themselves, as well as `packages/`.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D68960279
fbshipit-source-id: 7b62420c269dc1c1366ac9a827db078d34cb86c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47670
Now that we have `babel-plugin-syntax-hermes-parser` in `react-native/babel-preset` (since D63535216), it's no longer necessary to use `hermes-parser` directly in Metro in order to use newer Flow syntax.
Babel with `babel-plugin-syntax-hermes-parser` is generally preferable, because it intelligently falls back to parsing with Babel for any non-`flow` files.
See https://github.com/facebook/hermes/issues/1549 for context.
Changelog:
[General][Fixed] metro-config: Don't use `hermes-parser` by default, prefer `babel-plugin-syntax-hermes-parser`, which supports other syntax plugins.
Reviewed By: huntie
Differential Revision: D66002056
fbshipit-source-id: cf48acec347e2c0791872f8ca4b53f5f8af1c783
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47109
Fixes the `lint/sort-imports` errors that are now surfaced after fixing the lint configuration.
For a couple files, I added lint suppressions instead because the unsorted import ordering is important due to interleaved calls with side effects.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D64569485
fbshipit-source-id: 26415d792e2b9efe08c05d1436f723faae549882
Summary:
React Native [app template provided by the CLI](https://github.com/react-native-community/template) currently uses [`metro-config` directly for `MetroConfig` type](https://github.com/react-native-community/template/blob/main/template/metro.config.js#L7).
However, it doesn't have `metro-config` as neither a dependency or dev dependency, which can lead to version mismatches.
While this is obviously a mistake on the template repo side, `metro-config` versions aren't matched with `react-native` versions. Therefore, getting the correct version of `metro-config` from `react-native/metro-config` would require reflecting on `react-native/metro-config`'s package.json etc. which is far from ideal. In my opinion it's would be much better to expose `MetroConfig` type from `react-native/metro-config` directly.
Version mismatching can happen in a monorepo setup. Say we have the monorepo structure using Yarn Modern:
```tree
.
├── RN75-app (workspace)
├── RN76-app (workspace)
│ ├── metro.config.js
│ └── node_modules
│ └── react-native
│ └── metro-config (0.76)
│ └── node_modules
│ └── metro-config (version for 0.76)
└── node_modules
├── react-native
│ └── metro-config (0.75)
└── metro-config (version for 0.75)
```
`react-native@0.75` gets hoisted to the monorepo root while `react-native@0.76` sits in an RN 0.76 app workspace.
Say we have the following `RN76-app/metro.config.js` contents:
```js
const {getDefaultConfig, mergeConfig} = require('react-native/metro-config');
/**
* Metro configuration
* https://reactnative.dev/docs/metro
*
* type {import('metro-config').MetroConfig}
*/
const config = {};
module.exports = mergeConfig(getDefaultConfig(__dirname), config);
```
In this case, `require('react-native/metro-config')` would resolve to `RN76-app/node_modules/react-native/node_modules/metro-config` since `react-native/metro-config` is a (dev) dependency of the App.
However `import('metro-config).MetroConfig` would resolve to `node_modules/metro-config` since it's not a direct dependency.
This is how we have a mismatch - imported functions come from different packages than imported type.
## Changelog:
[GENERAL] [ADDED] - Expose `MetroConfig` type directly from `react-native/metro-config`.
Pull Request resolved: https://github.com/facebook/react-native/pull/46602
Test Plan:
`yarn build` to generate dist for `react-native/metro-config`, see it has the export of `MetroConfig`.
## Notes
If this PR gets approved, I'll submit relevant one to the CLI template.
Reviewed By: huntie
Differential Revision: D63258881
Pulled By: robhogan
fbshipit-source-id: e6f3c880eb4a0aa902c62932d58f243c38b07c2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46318
Configures the Metro by default to use the Hermes parser so that React Native can fully leverage all modern Flow language syntax.
NOTE: This does not affect `*.ts` and `*.tsx` files which will continue to use Babel. Metro has logic to enforce this regardless of the transform options.
Changelog:
[General][Changed] - Changed Metro default config to use Hermes parser, enabling the use of advanced Flow syntax in React Native.
Reviewed By: robhogan
Differential Revision: D62161923
fbshipit-source-id: 0f4c069d429517be16abcc6a2187cd23c6bd52d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45982
Changelog: [Internal]
Recently `src/private/renderer/errorhandling/ErrorHandlers.js` started showing up in some error stack traces, making LogBox less readable. This diff ensures we collapse these extra stack frames by default (as well as hide them in Fusebox, etc).
Reviewed By: hoxyq
Differential Revision: D61128294
fbshipit-source-id: 2ebcb47265aaf3281b669ed022c29978167f3e81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44362
Packages that are built and directly run in the monorepo no longer need to worry about
conditionally registering themselves to transpile Flow -> JS at runtime. Our build step
strips this file now.
Changelog: [Internal] changes in published packages no longer require conditional calls to Babel register.
Reviewed By: huntie
Differential Revision: D56839521
fbshipit-source-id: 6bec706c639f1ab4138e0b790be8a07654333046
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44339
We require the wrapper code for in repository calls to these packages directly from node (i.e. using CommonJS). This wrapper code typically sits at the entrypoint of the build packages (i.e. `index.js`).
NOTE: This unblocks an issue preventing me from landing further work on the `helloworld` cli replacing the community template.
## Problem:
The [flow-api-translator](https://www.npmjs.com/package/flow-api-translator) library doesn't allow CommonJS `module.exports` when generating TypeScript Type Defintions.
## Change
1. At the built time, this strips out our wrapper code and sets up the dist/ folder appropriately for npm distribution.
2. Updated the `package.json` files to consistently share Flow types
Changelog: [Internal] refactor build packages output to remove wrapper.
NOTE: Added better error messages when users deviated from the current pattern:
{F1501571608}
Reviewed By: huntie
Differential Revision: D56762162
fbshipit-source-id: f110b31e4ad780998dbc81a2482891ac8d8c6458
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43604
Changelog: [Internal]
Syncs the internal and OSS versions of `INTERNAL_CALLSITES_REGEX` in the default RN Metro config.
Reviewed By: robhogan
Differential Revision: D55237394
fbshipit-source-id: 8986a69f8beeafccbab3548d8a2137c0bf19e0b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43605
Changelog: [Internal]
Leverages https://developer.chrome.com/docs/devtools/x-google-ignore-list to mark more internal files as "third party", thus collapsing them by default in stack traces in modern versions of Chrome DevTools. The list of modules to collapse is the same one used by LogBox.
This likely only affects Meta usage, since Metro's default for [`isThirdPartyModule`](https://metrobundler.dev/docs/configuration/#isthirdpartymodule) already excludes all `node_modules`, but I'm making this change across Meta and OSS for consistency and to signal intent.
Reviewed By: huntie
Differential Revision: D55236653
fbshipit-source-id: d777ea31fb3d65608a487247924885c887ebbd94
Summary:
This adds `react-native/metro-config` to the monorepo build tool and emits the missing typescript declarations.
Right now, we do have typescript declarations on `metro-config`, but not `react-native/metro-config`. Which makes everything a bit harder extend from "[the default React Native metro config](https://github.com/facebook/react-native/pull/36502)" in Expo.
> Note, I also added the same `exports` block from `react-native/dev-middleware` for conformity.
One open question here is, why aren't we exporting _all_ helper functions from `metro-config`? To me, its a bit weird that we need both `metro-config` _and_ `react-native/metro-config` as `loadConfig` isn't exported.
## Changelog:
[INTERNAL] [FIXED] - Emit typescript declaration files for `react-native/metro-config`
Pull Request resolved: https://github.com/facebook/react-native/pull/41836
Test Plan:
Run the build tool, and check if the typescript declarations are emitted for `react-native/metro-config`.
```
yarn build metro-config
```
Reviewed By: hoxyq
Differential Revision: D51943453
Pulled By: huntie
fbshipit-source-id: cfaffe5660053fc9a9fcbe3dacf7f6ccc2bde01b
