[standards] Rewrite imports in YellowBox to use standard paths

[ide]

Summary

See #24316 for the motivation. This commit rewrites the imports in the YellowBox component.

Changelog

[General] [Changed] - Replaced Haste-style imports with standard path-style imports for YellowBox

Test Plan

Run RNTester and verify that it loads without any issues when it display a warning.

[analysis-bot]

Code analysis results:

• eslint found some issues. Run yarn lint --fix to automatically fix problems.

[analysis-bot]

prettier/prettier: Replace Registry,·Subscription,·IgnorePattern with ⏎··Registry,⏎··Subscription,⏎··IgnorePattern,⏎

[cpojer]

Please rebase once I land the .flowconfig change.

[matthargett]

@rigdern @empyrical @vincentriemer does this work for your out of tree platforms? It breaks in my tests because it misses the View.platform.js override (amongst others).

[vincentriemer]

Yeah this will likely make it impossible for rndom (or any other out of tree platform) to build.

For a simplest case I'd think about how an out-of-tree platform would provide an implementation for Libraries/Utilities/Platform.<whatever>.js if it is imported as a relative path. That's a module that definitely needs to be overridden by the platform while others may theoretically be refactored to not need any overrides. There just isn't any mechanism that I know of right now to override relative paths other than explicit path aliasing (which imo would be a huge pain to maintain).

[rigdern]

@acoates-ms see Matt's question above.

[acoates-ms]

Yeah, this will be a pain to support in out of tree platforms. Before we can remove the haste modules within RN, we need to have a solution for how out of tree platforms can work. (Or we need to get all of the code in core to be completely cross platform with no platform checks...)

[815065046]

easy

[acoates-ms]

@cpojer , did any write up get written on the proposed way to move out of tree platforms forward without haste?

I do think the new proposal will need some tooling / config work while the transition is taking place. Unless we get rid of haste completely within a single release, each platform will need to have its own hasteImpl, or the current one will need to know how to switch the haste project, rather than merging all the haste packages together as it currently does.

I've got one of our internal platforms over to the proposed mechanisms, but that platform doesn't have to worry quite so much about having all the tools / config work out of box since its internal only. I'd want to get that all sorted before moving react-native-windows over.

[ide]

Closing this PR since it's out of date.