maxjhandsome
/
react
0
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
react/scripts/flow/config/flowconfig

64 lines
1.4 KiB
Plaintext
Raw Normal View History

Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
[ignore]
Run Flow for each renderer separately (#12846) * Generate Flow config on install We'll need to do pre-renderer Flow passes with different configs. This is the first step to get it working. We only want the original version checked in. * Create multiple Flow configs from a template * Run Flow per renderer * Lint * Revert the environment consolidation I thought this would be a bit cleaner at first because we now have non-environment files in this directory. But Sebastian is changing these files at the same time so I want to avoid conflicts and keep the PR more tightly scoped. Undo. * Misc
2018-05-18 09:05:19 +08:00
.*/scripts/bench/.*
Make Flow work with your editor (#18664) We typecheck the reconciler against each one of our host configs. `yarn flow dom` checks it against the DOM renderer, `yarn flow native` checks it against the native renderer, and so on. To do this, we generate separate flowconfig files. Currently, there is no root-level host config, so running Flow directly via `flow` CLI doesn't work. You have to use the `yarn flow` command and pick a specific renderer. A drawback of this design, though, is that our Flow setup doesn't work with other tooling. Namely, editor integrations. I think the intent of this was maybe so you don't run Flow against a renderer than you intended, see it pass, and wrongly think you fixed all the errors. However, since they all run in CI, I don't think this is a big deal. In practice, I nearly always run Flow against the same renderer (DOM), and I'm guessing that's the most common workflow for others, too. So what I've done in this commit is modify the `yarn flow` command to copy the generated `.flowconfig` file into the root directory. The editor integration will pick this up and show Flow information for whatever was the last renderer you checked. Everything else about the setup is the same, and all the renderers will continue to be checked by CI.
2020-04-19 01:24:46 +08:00
.*/build/.*
Exclude fixtures from Flow config (#20302)
2020-11-20 10:45:03 +08:00
.*/fixtures/.*
Updates the DevTools test script to make it easier to test other URLs. (#19179)
2020-06-23 23:48:35 +08:00
.*/.tempUserDataDir/.*
Fix dead code elimination for feature flags (#11453) * Fix dead code elimination for feature flags Turning flags into named exports fixes dead code elimination. This required some restructuring of how we verify that flag types match up. I used the Check<> trick combined with import typeof, as suggested by @calebmer. For www, we can no longer re-export `require('ReactFeatureFlags')` directly, and instead destructure it. This means flags have to be known at init time. This is already the case so it's not a problem. In fact it may be better since it removes extra property access in tight paths. For things that we *want* to be dynamic on www (currently, only performance flag) we can export a function to toggle it, and then put it on the secret exports. In fact this is better than just letting everyone mutate the flag at arbitrary times since we can provide, e.g., a ref counting interface to it. * Record sizes
2017-11-06 22:14:48 +08:00
# These shims are copied into external projects:
Run Flow for each renderer separately (#12846) * Generate Flow config on install We'll need to do pre-renderer Flow passes with different configs. This is the first step to get it working. We only want the original version checked in. * Create multiple Flow configs from a template * Run Flow per renderer * Lint * Revert the environment consolidation I thought this would be a bit cleaner at first because we now have non-environment files in this directory. But Sebastian is changing these files at the same time so I want to avoid conflicts and keep the PR more tightly scoped. Undo. * Misc
2018-05-18 09:05:19 +08:00
.*/rollup/shims/facebook-www/.*
.*/rollup/shims/react-native/.*
Fix dead code elimination for feature flags (#11453) * Fix dead code elimination for feature flags Turning flags into named exports fixes dead code elimination. This required some restructuring of how we verify that flag types match up. I used the Check<> trick combined with import typeof, as suggested by @calebmer. For www, we can no longer re-export `require('ReactFeatureFlags')` directly, and instead destructure it. This means flags have to be known at init time. This is already the case so it's not a problem. In fact it may be better since it removes extra property access in tight paths. For things that we *want* to be dynamic on www (currently, only performance flag) we can export a function to toggle it, and then put it on the secret exports. In fact this is better than just letting everyone mutate the flag at arbitrary times since we can provide, e.g., a ref counting interface to it. * Record sizes
2017-11-06 22:14:48 +08:00
Iterated on Webpack configs until I got the inline and shell packages seemingly working
2019-08-15 00:24:35 +08:00
.*/node_modules/@snyk/.*
Run Flow for each renderer separately (#12846) * Generate Flow config on install We'll need to do pre-renderer Flow passes with different configs. This is the first step to get it working. We only want the original version checked in. * Create multiple Flow configs from a template * Run Flow per renderer * Lint * Revert the environment consolidation I thought this would be a bit cleaner at first because we now have non-environment files in this directory. But Sebastian is changing these files at the same time so I want to avoid conflicts and keep the PR more tightly scoped. Undo. * Misc
2018-05-18 09:05:19 +08:00
.*/node_modules/y18n/.*
.*/node_modules/chrome-devtools-frontend/.*
.*/node_modules/devtools-timeline-model/.*
.*/node_modules/create-react-class/.*
Ignore react-native-web in Flow checks (#17999)
2020-02-08 00:24:25 +08:00
.*/node_modules/react-native-web/.*
Run Flow for each renderer separately (#12846) * Generate Flow config on install We'll need to do pre-renderer Flow passes with different configs. This is the first step to get it working. We only want the original version checked in. * Create multiple Flow configs from a template * Run Flow per renderer * Lint * Revert the environment consolidation I thought this would be a bit cleaner at first because we now have non-environment files in this directory. But Sebastian is changing these files at the same time so I want to avoid conflicts and keep the PR more tightly scoped. Undo. * Misc
2018-05-18 09:05:19 +08:00
.*/__mocks__/.*
.*/__tests__/.*
Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
Refactor Host Config Infra (getting rid of .inline*.js) (#18240) * Require deep for reconcilers * Delete inline* files * Delete react-reconciler/persistent This no longer makes any sense because it react-reconciler takes supportsMutation or supportsPersistence as options. It's no longer based on feature flags. * Fix jest mocking * Fix Flow strategy We now explicitly list which paths we want to be checked by a renderer. For every other renderer config we ignore those paths. Nothing is "any" typed. So if some transitive dependency isn't reachable it won't be accidentally "any" that leaks.
2020-03-07 08:20:42 +08:00
# TODO: noop should get its own inlinedHostConfig entry
.*/packages/react-noop-renderer/.*
Exclude react-dom when flow checking other builds (#16737) This is because the HostConfig can't be guaranteed to be consistent with other code such as code that touches the DOM directly. Ideally we'd have a more systemic solution to this since it will pop up for other packages later too.
2019-09-20 03:41:51 +08:00
%REACT_RENDERER_FLOW_IGNORES%
Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
[include]
Make Flow work with your editor (#18664) We typecheck the reconciler against each one of our host configs. `yarn flow dom` checks it against the DOM renderer, `yarn flow native` checks it against the native renderer, and so on. To do this, we generate separate flowconfig files. Currently, there is no root-level host config, so running Flow directly via `flow` CLI doesn't work. You have to use the `yarn flow` command and pick a specific renderer. A drawback of this design, though, is that our Flow setup doesn't work with other tooling. Namely, editor integrations. I think the intent of this was maybe so you don't run Flow against a renderer than you intended, see it pass, and wrongly think you fixed all the errors. However, since they all run in CI, I don't think this is a big deal. In practice, I nearly always run Flow against the same renderer (DOM), and I'm guessing that's the most common workflow for others, too. So what I've done in this commit is modify the `yarn flow` command to copy the generated `.flowconfig` file into the root directory. The editor integration will pick this up and show Flow information for whatever was the last renderer you checked. Everything else about the setup is the same, and all the renderers will continue to be checked by CI.
2020-04-19 01:24:46 +08:00
./node_modules/
./packages/
./scripts/
Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
[libs]
Make Flow work with your editor (#18664) We typecheck the reconciler against each one of our host configs. `yarn flow dom` checks it against the DOM renderer, `yarn flow native` checks it against the native renderer, and so on. To do this, we generate separate flowconfig files. Currently, there is no root-level host config, so running Flow directly via `flow` CLI doesn't work. You have to use the `yarn flow` command and pick a specific renderer. A drawback of this design, though, is that our Flow setup doesn't work with other tooling. Namely, editor integrations. I think the intent of this was maybe so you don't run Flow against a renderer than you intended, see it pass, and wrongly think you fixed all the errors. However, since they all run in CI, I don't think this is a big deal. In practice, I nearly always run Flow against the same renderer (DOM), and I'm guessing that's the most common workflow for others, too. So what I've done in this commit is modify the `yarn flow` command to copy the generated `.flowconfig` file into the root directory. The editor integration will pick this up and show Flow information for whatever was the last renderer you checked. Everything else about the setup is the same, and all the renderers will continue to be checked by CI.
2020-04-19 01:24:46 +08:00
./node_modules/fbjs/flow/lib/dev.js
./scripts/flow/environment.js
./scripts/flow/react-devtools.js
./scripts/flow/react-native-host-hooks.js
./scripts/flow/react-relay-hooks.js
Re-add old Fabric Offscreen impl behind flag (#22018) * Re-add old Fabric Offscreen impl behind flag There's a chance that #21960 will affect layout in a way that we don't expect, so I'm adding back the old implementation so we can toggle the feature with a flag. The flag should read from the ReactNativeFeatureFlags shim so that we can change it at runtime. I'll do that separately. * Import dynamic RN flags from external module Internal feature flags that we wish to control with a GK can now be imported from an external module, which I've called "ReactNativeInternalFeatureFlags". We'll need to add this module to the downstream repo. We can't yet use this in our tests, because we don't have a test configuration that runs against the React Native feature flags fork. We should set up that up the same way we did for www.
2021-08-04 10:30:20 +08:00
./scripts/flow/xplat.js
Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
Re-enable Flow for ReactFiber and fix Flow issues (#12842) * Lint for untyped imports and enable Flow typing in ReactFiber * Re-enable Flow for ReactFiber and fix Flow issues * Avoid an invariant in DEV-only code I just introduced it, but on a second thought, it's better to keep it as a warning. * Address review
2018-05-18 00:14:12 +08:00
[lints]
untyped-type-import=error
Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
[options]
Add unstable_renderSubtreeIntoContainer and unstable_createPortal feature flags (#17880)
2020-01-22 05:17:42 +08:00
server.max_workers=4
Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
esproposal.class_static_fields=enable
esproposal.class_instance_fields=enable
[DevTools] Support extended source maps with named hooks information (#22010) ## Summary Adds support for statically extracting names for hook calls from source code, and extending source maps with that information so that DevTools does not have to directly parse source code at runtime, which will speed up the Named Hooks feature and allow it to be enabled by default. Specifically, this PR includes the following parts: - [x] Adding logic to statically extract relevant hook names from the parsed source code (i.e. the babel ast). Note that this logic differs slightly from the existing logic in that the existing logic also uses runtime information from DevTools (such as whether given hooks are a custom hook) to extract names for hooks, whereas this code is meant to run entirely at build time, so it does not rely on that information. - [x] Generating an encoded "hook map", which encodes the information about a hooks *original* source location, and it's corresponding name. This "hook map" will be used to generate extended source maps, included tentatively under an extra `x_react_hook_map` field. The map itself is formatted and encoded in a very similar way as how the `names` and `mappings` fields of a standard source map are encoded ( = Base64 VLQ delta coding representing offsets into a string array), and how the "function map" in Metro is encoded, as suggested in #21782. Note that this initial version uses a very basic format, and we are not implementing our own custom encoding, but reusing the `encode` function from `sourcemap-codec`. - [x] Updating the logic in `parseHookNames` to check if the source maps have been extended with the hook map information, and if so use that information to extract the hook names without loading the original source code. In this PR we are manually generating extended source maps in our tests in order to test that this functionality works as expected, even though we are not actually generating the extended source maps in production. The second stage of this work, which will likely need to occur outside this repo, is to update bundlers such as Metro to use these new primitives to actually generate source maps that DevTools can use. ### Follow-ups - Enable named hooks by default when extended source maps are present - Support looking up hook names when column numbers are not present in source map. - Measure performance improvement of using extended source maps (manual testing suggests ~4 to 5x faster) - Update relevant bundlers to generate extended source maps. ## Test Plan - yarn flow - Tests still pass - yarn test - yarn test-build-devtools - Named hooks still work on manual test of browser extension on a few different apps (code sandbox, create-react-app, facebook). - For new functionality: - New tests for statically extracting hook names. - New tests for using extended source maps to look up hook names at runtime.
2021-08-11 22:46:19 +08:00
esproposal.optional_chaining=enable
Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
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%
Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
munge_underscores=false
suppress_type=$FlowIssue
suppress_type=$FlowFixMe
suppress_type=$FixMe
Update flow to 0.31 (#7557)
2016-08-26 00:43:28 +08:00
suppress_type=$FlowExpectedError
Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
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
Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
suppress_comment=\\(.\\|\n\\)*\\$FlowFixedInNextDeploy
Update flow to 0.31 (#7557)
2016-08-26 00:43:28 +08:00
suppress_comment=\\(.\\|\n\\)*\\$FlowExpectedError
Set up Flow - Yay! (#6682) This just configures flow to be checked and fixes our existing Flow typed files. Possible enhancements: Export .js.flow declarations from the build. Unclear whether this will be a supported workflow in the future or not, so let's wait on that. We should fail builds and CI on Flow errors. Ideally we should lint for Flow style guides (like no space before colon).
2016-05-04 05:37:13 +08:00
[version]
Update to flow 0.97 (#17892)
2020-01-25 02:52:38 +08:00
^0.97.0