Run Flow for each renderer separately #12846
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
gaearon
requested review from
sophiebits,
bvaughn,
sebmarkbage,
flarnie and
acdlite
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.
|
This is ready for review. |
|
Is it still possible to spawn a Flow server? |
|
Yes, that's what The full check has moved into |
acdlite
approved these changes
May 17, 2018
elas7
added a commit
to elas7/react
that referenced
this pull request
Aug 14, 2018
`flow-coverage-report` stopped working after Flow was set to run for each renderer separately (facebook#12846). It happened because `flow-coverage-report` calls `flow coverage`, and that command doesn't work without a `.flowconfig` in a parent directory of every file checked. This is fixed by creating a temporary `.flowconfig` in the project root before running `flow-coverage-report`. This fix also allows to move `.flowcoverage` out of the project root, and to select a renderer before generating the coverage report. Internally, this is done by rewriting `writeConfig()` to accept a `rootFolder` argument. If `rootFolder` is true, a config is made in the root folder, with the right relative paths.
elas7
added a commit
to elas7/react
that referenced
this pull request
Aug 14, 2018
`flow-coverage-report` stopped working after Flow was set to run for each renderer separately (facebook#12846). As discussed in facebook#13393, this is hard to fix without adding complexity to `.flowconfig`'s generation.
gaearon
pushed a commit
that referenced
this pull request
Aug 14, 2018
|
@gaearon Should we update the |
|
Sure. |
|
Are you working on this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds per-renderer Flow commands:
yarn flow domyarn flow fabricyarn flow nativeyarn flow testIf you forget to specify the one you need during local development,
yarn flowwill prompt you to do so. It should be possible to even run them in parallel although I’d expect it to be super slow so in practice you’ll probably use one at a time.The typechecks are currently exactly the same between renderers. This is a preparation for #12792 which will shim the host config types for each renderer separately.
The
yarn flow-cicommand that runs on the CI is changed to run Flow with each renderer, one by one.Internally, this works by having separate Flow configs in different directories (thus making Flow treat them as isolated from each other). We generate Flow configs from a single master template if you run
yarn,yarn flow, oryarn flow-ci.