3 Commits

Author	SHA1	Message	Date
Nick Gerleman	7858a2147f	Enforce compatibility with exactOptionalPropertyTypes (#36345) ... 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 https://github.com/DefinitelyTyped/DefinitelyTyped/commit/694c663a9486dbe7794d5eb894a691ee9ded318a). 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	2023-03-08 00:14:56 -08:00
Sebastian Silbermann	8568b93733	react-native: Use number literals in TypeScript types for FileReader and XMLHttpRequest states (#36000) ... Summary: Mostly to improve compat in codebases where `lib.dom.d.ts` is loaded alongside RN. TS 5.0 updates to `lib.dom.d.ts` added number literals for these states as well so the abstract `number` type from RN was no longer compatible. Forward-port of https://github.com/DefinitelyTyped/DefinitelyTyped/pull/64144 Underlying flow types: - https://github.com/facebook/react-native/blob/v0.71.1/Libraries/Blob/FileReader.js#L33-L35 - https://github.com/facebook/react-native/blob/v0.71.1/Libraries/Network/XMLHttpRequest.js#L54-L58 ## Changelog [GENERAL] [CHANGED] - Use number literals in TypeScript types for `FileReader` and `XMLHttpRequest` states Pull Request resolved: https://github.com/facebook/react-native/pull/36000 Test Plan: - [x] https://github.com/DefinitelyTyped/DefinitelyTyped/pull/64144 green Reviewed By: christophpurrer Differential Revision: D42849886 Pulled By: jacdebug fbshipit-source-id: c3cf2ac4f5f53ab889a9190583486da4627d3dcc	2023-01-30 15:13:31 -08:00
Nick Gerleman	5d26ceaa23	Fixup TS Organization (#35169) ... Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/35169 This reorganizes typing structure a bit. `Utilities.d.ts` was originally added for utilitiy types but I ended up leaving it a grab bag of types that didn't belong to any individual bit of code. Out of what is in it right now, `Insets` was actually public, and seems to have been imported. We also run into files around the renderer which are [currently overwritten](https://github.com/facebook/react-native/commits/e286da25fc83324363486eb668806aca179f74b3/Libraries/Renderer/implementations/ReactNativeRenderer.d.ts) by the React sync script. Finally, all of the top-level imports of `Utilities` were auto-generated by VS Code, but fail in real apps. I think this is because our tsconfig sets a `baseUrl` to allow resolution from the types folder, so the tooling in the RN repo will use that, but it breaks in real apps that don't have that mapping. This splits all these up into a couple separate directories that are hopefully easier to reason about, and removes `Omit` which has been a builtin type for quite some time (we were actually already using built-in `Omit`). Changelog: [General][Fixed] - Fixup TS Organization Reviewed By: cipolleschi Differential Revision: D40932319 fbshipit-source-id: 0b6e3e3eda603885b4dc01dcb9f5233aa546d128	2022-11-02 14:58:37 -07:00