Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47104
In https://github.com/facebook/react-native/pull/46082, the lint configuration for `lint/sort-imports` was accidentally removed.
This has happened on more than one occasion in the past. In order to prevent this from happening again in the future, I'm also adding a Jest integration test to verify that this lint rule is enabled in the `eslintrc.js` configuration.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D64547410
fbshipit-source-id: ec4f14aff140691b644189dfa3116a3d39285f80
Summary:
## Summary
There are old references to the react-native/template. This code has
moved to react-native-community/template.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/46082
Test Plan:
CI
closesfacebook/metro#1324
Reviewed By: cipolleschi
Differential Revision: D61472439
Pulled By: blakef
fbshipit-source-id: fc40145c03002a7c3117b72d07981a96aa3d8760
Summary:
This gives Frameworks more control in selecting specific tasks and integrating the return types data in their UI. For example piping `stdout` to the user or using packages like [Listr2](https://www.npmjs.com/package/listr2) to run tasks in parallel and show progress.
The ordering is suggestive (but also enforced by some assertions). Frameworks are free to do what they want.
The order was implicit in the previous data structure with lists of Tasks, but made it difficult to tap into each async task.
I've also had to rework how we transpile the code if directly executed from the monorepo. This keeps our:
- flow types valid,
- allows the core-cli-utils package to be built (to generate TypeScript types and a valid npm module), and
- allows direct transpiled execution as a yarn script.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D56242487
fbshipit-source-id: a1a18f14a4aef53a98770462c8ebdef4111f0ab4
Summary:
`Image.getSize/getSizeWithHeaders` are still working in old fashioned "callback" way
```tsx
Image.getSize(uri, function success(width,height) { }, function failure(){ } ); // undefined
Image.getSizeWithHeaders(uri, headers, function success(width,height) { }, function failure(){ } ); // undefined
```
But in 2024 more developers prefer use async/await syntax for asynchronous operations
So, in this PR I added support for Promise API with **backward compatibility**, modern way:
```tsx
Image.getSize(uri).then(({width,height}) => { }); // Promise
Image.getSizeWithHeaders(uri, headers).then(({width,height}) => { }); // Promise
```
bypass-github-export-checks
## Changelog:
[GENERAL] [ADDED] - `Image.getSize/getSizeWithHeaders` method returns a promise if you don't pass a `success` callback
Pull Request resolved: https://github.com/facebook/react-native/pull/42895
Test Plan:
1. ts: New test cases added in typescript tests
2. runtime: you can create a new project and put code from this PR into the next files
a. `node_modules/react-native/Libraries/Image/Image.android.js`
b. `node_modules/react-native/Libraries/Image/Image.ios.js`
Reviewed By: javache
Differential Revision: D53919431
Pulled By: cipolleschi
fbshipit-source-id: 508b201e17e0ffda2e67aa5292bf9906b88d09c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42385
This adds support for having JS files in a `src` directory within the `react-native` package. The plan is to have 2 subdirectories there:
* `react-native/src/private` for private modules, with any nested directories (e.g.: `react-native/src/private/dom/nodes/ReadOnlyNode.js`).
* `react-native/src/public` for public modules, without nested directories. The plan is that the individual modules created in this directory will be public through the index module or directly via something like `react-native/View` (mapped to `react-native/src/public/View`, or a `dist` directory in the published npm package—details TBD).
The enforcement of private modules being inaccessible from outside the `react-native` package will be added soon by huntie.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52875999
fbshipit-source-id: 914ed806f2cb86857e2cb7b760292c2190b5b14e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41333
Enables the `sort-imports` lint rule introduced in D39907799 in ~all files, rather than just in `react-native/Libraries`.
We exclude only `packages/react-native/template`, in order to (1) minimise noise for projects that are tracking updates to the template, (2) avoid the possibility of something breaking if the `react-native` import isn't at the top of `template/index.js`, (3) avoid leaking a reference to `lint/sort-imports` to the template (which doesn't ship with this rule) via an ESLint suppression comment.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D51025811
fbshipit-source-id: a62b0d6ebc5323116a4b2f1b69c4e8d48cde3215
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39064
Creates a new lint rule that enforces the following constraints:
- `react-native/monorepo` cannot have `dependencies`.
- `react-native` cannot have `devDependencies`.
This also includes a lengthy comment in the rule definition explaining why these constraints exist, so that future contributors can make an informed decision when reconsidering these constraints.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D48448633
fbshipit-source-id: 26b0d74b9120ddfd2a6a72bb91f86a98c8d679ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37636
Moves `flow-typed/` directory from `packages/react-native/flow-typed/` to the repo root.
- This is a more suitable location for `flow-typed` definitions for 3P dependencies to be used across React Native packages.
- **Breaking**: We no longer publish these 3P libdefs as part of the `react-native` package (assuming that external use of React Native with Flow is extremely rare, and that these projects can manage their own package libdefs).
Changelog:
[General][Breaking] Remove included `flow-typed/` directory from the `react-native` package
- **Upgrade instructions**: Projects using Flow should install or replicate third party `flow-typed` definitions for React Native dependencies — see https://github.com/facebook/react-native/tree/main/flow-typed and [#37636](https://github.com/facebook/react-native/pull/37636).
Reviewed By: hoxyq
Differential Revision: D46313482
fbshipit-source-id: 3d97d5408e44dd43132664c4933f3ff1075f90a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37347
This fixes the file-structure of `eslint-config-react-native-communtiy`, and `eslint-plugin-react-native-communtiy` to match the name they were renamed to as part of 0.72.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D45721173
fbshipit-source-id: 7ad784dbf56fb4cd05d7dba608e6d5064392e43d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36345
`exactOptionalPropertyTypes` is a TypeScript 4.4+ option set by users which changes behavior of optional properties, to disable accepting explicit `undefined`.
This is not enabled when using `--strict`, and is stricter than Flow, leading to most of the typings having an `| undefined` unique to TypeScript (added with 694c663a94).
We have not always followed this (I have myself previously assumed the two are equivalent). We can enforce that the convention is followed with a plugin `eslint-plugin-redundant-undefined`. This forces us to declare that every optional property accepts an explicit undefined (which Flow would allow). Alternatively, if we do not want to support this, we can enable the existing dtslint rule `no-redundant-undefined`.
Changelog:
[General][Fixed] - Enforce compatibility with `exactOptionalPropertyTypes`
Reviewed By: lunaleaps
Differential Revision: D43700862
fbshipit-source-id: 996094762b28918177521a9471d868ba87f0f263
Summary:
The [monorepo RFC](https://github.com/react-native-community/discussions-and-proposals/pull/480) calls for renaming:
* `react-native-community/eslint-config` -> `react-native/eslint-config`
* `react-native-community/eslint-plugin` -> `react-native/eslint-plugin`
It also calls for the versions to be aligned with the rest of main -- currently `0.72.0`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General][Changed] - Renamed `react-native-community/eslint-config` to `react-native/eslint-config` v0.72.0 to align with other packages
[General][Changed] - Renamed `react-native-community/eslint-plugin` to `react-native/eslint-plugin` v0.72.0 to align with other packages
Pull Request resolved: https://github.com/facebook/react-native/pull/34581
Test Plan:
First test is to run `yarn lint`, and verify that output matches before and after this change.
Second test is to change the ESLint config to use the "old" packages (under `react-native-commnuity`) and run `yarn lint` to make sure that they work as expected. This is what customers will experience, until they manually move to the new ESLint packages.
Reviewed By: cortinico
Differential Revision: D41520500
Pulled By: hoxyq
fbshipit-source-id: a61e5ae15d5aaf11f0143a3b0257a60a03b1550b
Summary:
Creates a new `valid-flow-typed-signature` ESLint rule that validates the `flow-typed` signatures at the top of each file.
This lint rule will discourage contributors from locally forking the `flow-typed` definitions. Instead, any changes should be submitted as patches to the upstream definition in: https://github.com/flow-typed/flow-typed
Changelog:
[Internal]
Reviewed By: rickhanlonii
Differential Revision: D39868721
fbshipit-source-id: e5e3ffe7568dbe52c9b598b53110b0fcbcad3e38
Summary:
Introduces a portable bundle that implements the `sort-imports` ESLint rule that we use internally at Meta, to the React Native repository.
As a consequence of the rapid changes that occur to this rule internally (and the desire to minimize red tape for Meta engineers), the portable bundle is built with Rollup with a lot of context omitted.
Changelog:
[Internal]
Reviewed By: skinsshark
Differential Revision: D39907799
fbshipit-source-id: 58fb6dc08030f20ac02c0e3fd1b175e22e4d74c0
Summary:
Removes the `error-subclass-name` ESLint rule from `react-native/eslint-plugin`, and implements a new `require-extends-error` ESLint rule inside the React Native repository. This rule was only intended to be used for internal development of React Native.
This will change `react-native/eslint-plugin` to no longer provide the `error-subclass-name` rule.
NOTE: One behavior difference here is that I also implemented the desired behavior of checking classes that extend `Library.SomeError`.
Changelog:
[General][Removed] - `react-native/eslint-plugin` no longer provides the `error-subclass-name` rule.
Reviewed By: lunaleaps
Differential Revision: D39858882
fbshipit-source-id: 27b53216d77a15b3425bd9669dbc9d954c1c61da
Summary:
Moves the `no-haste-imports` ESLint rule into the React Native repository because it was only intended to be used for internal development of React Native.
This will change `react-native/eslint-plugin` to no longer provide the `no-haste-imports` rule.
Changelog:
[General][Removed] - `react-native/eslint-plugin` no longer provides the `no-haste-imports` rule.
Reviewed By: lunaleaps
Differential Revision: D39858883
fbshipit-source-id: b8d91ce5996b615341cf60c6f839afac1e26dac9
Summary:
Creates an ESLint rule that prohibits (and autofixes) imports from `react-native` or `react-native/path/to/file`, within the React Native repository.
The ESLint rule is configured using the `eslint-plugin-lint` package instead of `react-native/eslint-plugin` because the rule is only applicable to the React Native repository. The rule does not (and should not) be publicly facing, and changes to the rule should not require publishing new versions of `react-native/eslint-plugin`. (As a follow-up, the `no-haste-imports` rule should be migrated over from `react-native/eslint-plugin`.)
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D39831222
fbshipit-source-id: 566330e6df77fdff5ce755324b9f592b9365019e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34801
D39796598 (8cdc9e7f04) broke this CircleCI job, causing failures for `dtslint` and `prettier`. This fixes both issues, by upating formatting, and removing types from `legacy-properties.d.ts` that we no longer export.
These were not flagged by sandcastle. It looks like this is because:
1. We run eslint, but not dtslint internally
2. Arcanist will ignore anything under a "vendor" directory, while we do not exlude anything from the prettier check in OSS.
I also updated the eslint config to lint any TypeScript that appears outside the types directory, since typings are now spread out.
Changelog:
[Internal][Fixed] - Fix `analyze_code` CircleCI Job
Reviewed By: cipolleschi
Differential Revision: D39848604
fbshipit-source-id: 844dfe26e4b618059542b29df163402079c39322
Summary:
## Changelog
[General] [Added] - Add `types` folder to house TypeScript types.
Release TypesScript types with react-native and eventually deprecate [types/react-native](https://www.npmjs.com/package/types/react-native).
The current plan is to release types/react-native for 0.70 and 0.71 while also maintaining types here. This will result in some double maintenance until 0.72 but will give community time to move off of types/react-native.
After this lands, there have been changes on `main` of types that we need to update. Then, when we release 0.71 from DefinitelyTyped, we can simply copy over the `types` folder from this repo.
Pull Request resolved: https://github.com/facebook/react-native/pull/34614
Test Plan:
`yarn run test-typescript` for linting types
* Created a new project using the TS template and my local clone of `react-native` on this branch.
`npx react-native init MyTSApp --version <path-to-my-local-rn-repo> --template react-native-template-typescript`
* Updated the `package.json` to remove `types/react-native`
* Deleted my node_modules and re-ran yarn
* Opened MyTSApp in VSCode and verified the type suggestions appeared and cmd+click to defnitions took me to the node_module dependency `react-native/types`
## Danger is failing on this PR and it's expected
as it runs off the changes on `main`. [This is expected](https://docs.github.com/en/github-ae@latest/actions/using-workflows/events-that-trigger-workflows?fbclid=IwAR2_AE0Jwndt8Gu-iTQnxGxLJq7nakbi7sz8jwZ6U62JWLSdcZuvjcQ6WvE#pull_request_target). However testing it locally passes. Once merged, and these changes are on `main`, danger will pass again.
```
$ react-native/packages/react-native-bots
❯ yarn danger pr https://github.com/facebook/react-native/pull/34614
yarn run v1.22.19
$ ..react-native/node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/34614
Starting Danger PR on facebook/react-native#34614
Danger: ✓ found only warnings, not failing the build
## Warnings
🔒 package.json - <i>Changes were made to package.json. This will require a manual import by a Facebook employee.</i>
✨ Done in 13.24s.
```
Reviewed By: mdvacca
Differential Revision: D39479137
Pulled By: lunaleaps
fbshipit-source-id: 1d506f812d566b783b6e79104cd6339b077a42a7
Summary:
Changes the React Native base ESLint configuration to consume `react-native-community/eslint-config` as a [yarn workspace](https://classic.yarnpkg.com/lang/en/docs/workspaces/), so that any dependencies of `react-native-community/eslint-config` can also be resolved from the root directory of `react-native`.
Previously, `~/.eslintrc.js` extended `react-native-community/eslint-config` using a relative file path. This is problematic because if any dependencies (notably, optional peer dependencies such as some of the TypeScript dependencies) are not already installed at the root directory of `react-native`, running ESLint could fail to resolve any required dependencies. In other words, there was an implicit dependency that `react-native/yarn.lock` would also contain any dependencies required by `react-native/packages/eslint-config-react-native-community/yarn.lock`.
With this change, running `yarn` from the root directory of `react-native` will also install any dependencies of `react-native-community/eslint-config`, and it will also symlink `react-native/node_modules/react-native-community/eslint-config` to `../../packages/eslint-config-react-native-community` (meaning any local changes to the config will still be reflected during active development).
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/34423
Test Plan:
Successfully install dependencies and run ESLint.
```
$ cd react-native
$ yarn
$ yarn lint
```
Successfully run Danger on https://github.com/facebook/react-native/pull/34401 (which would previously fail because `typescript-eslint/eslint-plugin` could not be resolved from the root directory of `react-native`):
```
$ cd react-native/bots
$ yarn
$ node ./node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/34401
```
Reviewed By: NickGerleman
Differential Revision: D38710285
Pulled By: yungsters
fbshipit-source-id: a06ceea0884a90be60f6f5db9a5d42be52a951d5
Summary:
Changelog: [internal]
- Upgrade ESLint version to the latest
- Upgrade ESLint plugin versions to the latest to ensure compatibility
- Switch from eslint-plugin-flowtype to eslint-plugin-ft-flow
- Updates lint suppressions - all `flowtype/` rules to `ft-flow/`
### `flowtype` vs `ft-flow`
`eslint-plugin-flowtype` is well out of date and no-longer maintained. It's been abandoned by its owner. This means it crashes on ESLint v8.
`eslint-plugin-ft-flow` is a fork of the above and is maintained by the same people that own the `flow-typed` project.
Reviewed By: jacdebug
Differential Revision: D37727177
fbshipit-source-id: 516be42f947fec9c886526c182a608b3311c0b50
Summary:
`hermes-eslint` is built by Meta to work with the latest Flow code.
It follows the latest ESLint standards and AST, and has a true scope analyser to ensure best compatibility with core ESLint rules.
Reviewed By: motiz88
Differential Revision: D37181192
fbshipit-source-id: 1f59e01f306792e67a4977435c5c77e0000d960a
