Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48665
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling
## This diff
- Updates files in Libraries/Utilities to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates Jest mocks of the `Platform` module, which happened to touch a lot of test files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Utilities` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: huntie
Differential Revision: D68152910
fbshipit-source-id: 07f3a0957f1dbaf44f53974c6f28b273558406eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48901
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in `Libraries/Text`, `Libraries/Share` and `Libraries/Settings` to use `export` syntax.
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updates the public API snapshot *(intented breaking change)*
Changelog:
[General][Breaking] - Files inside `Libraries/Text`, `Libraries/Share` and `Libraries/Settings` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: huntie
Differential Revision: D68562844
fbshipit-source-id: bd71a341e33d3629121aa61549139c4b1cd62c3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44887
The previous inexact object types and documentation for Share.share()'s arguments have led to confusion in how this library should be used. This diff updates the argument types to be more explicit, and rewrites some of the documentation for clarity.
Changelog:
[General][Breaking] Update `Share.share()`'s argument types to be more explicit.
Reviewed By: NickGerleman
Differential Revision: D58224906
fbshipit-source-id: 5ac8efe7caa0ecdd430fa7a1951c73c4acd8c6a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42402
Now that we have 2 top level directories for JS files in the `react-native` package, we need to choose where to put the native module and native component specs, because our current infra only supports a single directory.
The options we had are:
1. Keep specs in the current directory (`Libraries`). This is a problem because it encourages us to keep adding modules in this "deprecated" directory.
2. Move specs to the new `src` directory. This requires moving the current files, but from now only we can create new specs in a private directory.
3. Modify the infra to allow multiple directories. This changes the public API for something it's likely only going to be used here.
In this PR I went for option 2) because it's the most future-proof, even though it requires a little bit more work now. I created a script to automatically copy all the specs for modules and components to `src/private/specs/components` and `src/private/specs/modules`, and changed their current locations to serve as a proxy for the new location (to avoid breaking a potentially public API).
`src/private/specs` isn't meant to be their final location. We should probably still colocate native module/component specs with the rest of their code, but we can do so when we move the code from `Libraries` to `src/private`.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D52919566
fbshipit-source-id: 6de8a2d2b6077e4f884386567721c6bd2b88a5d3