react/scripts/flow/config/flowconfig

55 lines
1.1 KiB
Plaintext
Raw Normal View History

[ignore]
.*/scripts/bench/.*
# These shims are copied into external projects:
.*/rollup/shims/facebook-www/.*
.*/rollup/shims/react-native/.*
.*/node_modules/@snyk/.*
.*/node_modules/y18n/.*
.*/node_modules/chrome-devtools-frontend/.*
.*/node_modules/devtools-timeline-model/.*
.*/node_modules/create-react-class/.*
.*/node_modules/react-native-web/.*
.*/__mocks__/.*
.*/__tests__/.*
%REACT_RENDERER_FLOW_IGNORES%
[include]
../../../node_modules/
../../../packages/
../../../scripts/
[libs]
../../../node_modules/fbjs/flow/lib/dev.js
../environment.js
../react-devtools.js
../react-native-host-hooks.js
[lints]
untyped-type-import=error
[options]
server.max_workers=4
esproposal.class_static_fields=enable
esproposal.class_instance_fields=enable
Resolve host configs at build time (#12792) * Extract base Jest config This makes it easier to change the source config without affecting the build test config. * Statically import the host config This changes react-reconciler to import HostConfig instead of getting it through a function argument. Rather than start with packages like ReactDOM that want to inline it, I started with React Noop and ensured that *custom* renderers using react-reconciler package still work. To do this, I'm making HostConfig module in the reconciler look at a global variable by default (which, in case of the react-reconciler npm package, ends up being the host config argument in the top-level scope). This is still very broken. * Add scaffolding for importing an inlined renderer * Fix the build * ES exports for renderer methods * ES modules for host configs * Remove closures from the reconciler * Check each renderer's config with Flow * Fix uncovered Flow issue We know nextHydratableInstance doesn't get mutated inside this function, but Flow doesn't so it thinks it may be null. Help Flow. * Prettier * Get rid of enable*Reconciler flags They are not as useful anymore because for almost all cases (except third party renderers) we *know* whether it supports mutation or persistence. This refactoring means react-reconciler and react-reconciler/persistent third-party packages now ship the same thing. Not ideal, but this seems worth how simpler the code becomes. We can later look into addressing it by having a single toggle instead. * Prettier again * Fix Flow config creation issue * Fix imprecise Flow typing * Revert accidental changes
2018-05-19 18:29:11 +08:00
# Substituted by createFlowConfig.js:
%REACT_RENDERER_FLOW_OPTIONS%
munge_underscores=false
suppress_type=$FlowIssue
suppress_type=$FlowFixMe
suppress_type=$FixMe
2016-08-26 00:43:28 +08:00
suppress_type=$FlowExpectedError
Update Flow and Fix Hydration Types (#11493) * Update Flow * Fix createElement() issue The * type was too ambiguous. It's always a string so what's the point? Suppression for missing Flow support for {is: ''} web component argument to createElement() didn't work for some reason. I don't understand what the regex is testing for anyway (a task number?) so I just removed that, and suppression got fixed. * Remove deleted $Abstract<> feature * Expand the unsound isAsync check Flow now errors earlier because it can't find .type on a portal. * Add an unsafe cast for the null State in UpdateQueue * Introduce "hydratable instance" type The Flow error here highlighted a quirk in our typing of hydration. React only really knows about a subset of all possible nodes that can exist in a hydrated tree. Currently we assume that the host renderer filters them out to be either Instance or TextInstance. We also assume that those are different things which they might not be. E.g. it could be fine for a renderer to render "text" as the same type as one of the instances, with some default props. We don't really know what it will be narrowed down to until we call canHydrateInstance or canHydrateTextInstance. That's when the type is truly refined. So to solve this I use a different type for hydratable instance that is used in that temporary stage between us reading it from the DOM and until it gets refined by canHydrate(Text)Instance. * Have the renderer refine Hydratable Instance to Instance or Text Instance Currently we assume that if canHydrateInstance or canHydrateTextInstance returns true, then the types also match up. But we don't tell that to Flow. It just happens to work because `fiber.stateNode` is still `any`. We could potentially use some kind of predicate typing but instead of that I can just return null or instance from the "can" tests. This ensures that the renderer has to do the refinement properly.
2017-11-12 09:00:33 +08:00
suppress_comment=\\(.\\|\n\\)*\\$FlowFixMe
suppress_comment=\\(.\\|\n\\)*\\$FlowIssue
suppress_comment=\\(.\\|\n\\)*\\$FlowFixedInNextDeploy
2016-08-26 00:43:28 +08:00
suppress_comment=\\(.\\|\n\\)*\\$FlowExpectedError
[version]
2020-01-25 02:52:38 +08:00
^0.97.0