Incomplete check for @react-native/metro-config

[tido64]

Environment

n/a

Description

The check for whether @react-native/metro-config is incomplete because metro.config.js is not necessarily self-contained:

cli/packages/cli-plugin-metro/src/tools/loadMetroConfig.ts

Lines 100 to 104 in 3569633

	if (
	!/['"']@react-native\/metro-config['"']/.test(
	fs.readFileSync(projectConfig.filepath, 'utf8'),
	)
	) {

Metro config can be split in several files (or modules) for reusability. The check fails for these scenarios. Example: microsoft/rnx-kit#2481

Reproducible Demo

1. Instantiate a react-native project with 0.72
2. Refactor metro.config.js by moving the @react-native/metro-config import to a separate file
3. Bundle

[tido64]

Suggestion: Can we add a field in @react-native/metro-config that only gets set if it's used instead?

[kelset]

cc @huntie

[huntie]

@tido64 Yeah I've considered this. It would require adding an untyped metadata key, e.g. '__metaBaseConfig': '@react-native/metro-config' — which Metro's mergeConfig would not yet handle. Stopped short of this because we strongly recommend a single-file Metro config — but if you have clear/consistent use cases we can consider building this in.

There's also the workaround of a "suppression" comment within (e.g. at the top of) the file:

// Extends '@react-native/metro-config'

Related:

• breaking: Remove fallback flow for Metro config defaults (0.73) #1972
• [docs] Add Metro configuration guide, update Metro config references facebook/react-native-website#3772

[tido64]

@tido64 Yeah I've considered this. It would require adding an untyped metadata key, e.g. '__metaBaseConfig': '@react-native/metro-config' — which Metro's mergeConfig would not yet handle. Stopped short of this because we strongly recommend a single-file Metro config — but if you have clear/consistent use cases we can consider building this in.

I don't think that will scale as you have more teams working with React Native. At Microsoft, all teams use a shared Metro config unless they have a very good reason not to. We're not going back to having individual teams configuring Metro for themselves.

There's also the workaround of a "suppression" comment within (e.g. at the top of) the file:

// Extends '@react-native/metro-config'

That's currently what we're telling people to do: microsoft/rnx-kit#2481

[huntie]

@tido64 Planned fix incoming.

[huntie]

Change has landed and should be shipped in React Native 0.72.2.

[tido64]

Change has landed and should be shipped in React Native 0.72.2.

Thank you!