Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add smoke test for flight fixture #28350

Merged
merged 11 commits into from
Feb 21, 2024
Merged

Conversation

eps1lon
Copy link
Collaborator

@eps1lon eps1lon commented Feb 15, 2024

Not working in CI yet. Needs Node.js 20

Summary

The test just opens the page for now and asserts that no console errors or uncaught errors happens. This would've caught the breakage that was fixed in #28352

How did you test this change?

  • CI
  • yarn build && cd fixtures/flight && yarn && yarn build && yarn build && yarn test

@facebook-github-bot facebook-github-bot added CLA Signed React Core Team Opened by a member of the React Core Team labels Feb 15, 2024
@react-sizebot
Copy link

react-sizebot commented Feb 15, 2024

Comparing: 59fe6c3...0a7acc5

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name +/- Base Current +/- gzip Base gzip Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js = 176.86 kB 176.86 kB = 55.14 kB 55.14 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js = 179.00 kB 179.00 kB = 55.78 kB 55.78 kB
facebook-www/ReactDOM-prod.classic.js = 591.78 kB 591.78 kB = 104.51 kB 104.51 kB
facebook-www/ReactDOM-prod.modern.js = 575.07 kB 575.07 kB = 101.51 kB 101.51 kB
test_utils/ReactAllWarnings.js Deleted 66.50 kB 0.00 kB Deleted 16.27 kB 0.00 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show
Name +/- Base Current +/- gzip Base gzip Current gzip
test_utils/ReactAllWarnings.js Deleted 66.50 kB 0.00 kB Deleted 16.27 kB 0.00 kB

Generated by 🚫 dangerJS against 0a7acc5

@sebmarkbage
Copy link
Collaborator

You can test it against
#28352
and
#28353

It should still have first one but pass after both.

There's still an issue that you have to run yarn build before yarn dev because of a babel cache poisoning issues.

@eps1lon eps1lon force-pushed the test/fixture-flight branch 2 times, most recently from 418f4da to 51401ff Compare February 16, 2024 10:45
@eps1lon
Copy link
Collaborator Author

eps1lon commented Feb 16, 2024

#28353

It should still have first one but pass after both.

Not sure what #28353 fixes. Is there a specific interaction that's broken? From opening the fixture and clicking around I can't immediately see what's broken.

working_directory: fixtures/flight
command: |
yarn build
# Need to build twice for unknown reasons
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@unstubbable unstubbable Feb 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe if you set FAST_REFRESH=false, you can skip the build step completely. This is how I verified this locally: rm -rf build ./node_modules/.cache && FAST_REFRESH=false yarn test. My understanding is that this avoids needing to transform the node_modules/react-refresh ES modules (which seems to occur too late on the first run).

Copy link
Contributor

@unstubbable unstubbable Feb 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, this would just mask the issue that users might run into when trying to run the flight fixture locally. Is fast refresh that useful for the fixture? If not, we could also disable it in fixtures/flight/config/env.js, and not only in the CI.

@unstubbable
Copy link
Contributor

unstubbable commented Feb 16, 2024

#28353
It should still have first one but pass after both.

Not sure what #28353 fixes. Is there a specific interaction that's broken? From opening the fixture and clicking around I can't immediately see what's broken.

Without the fix from #28353 I do get hydration mismatches because the chunk script tags (mentioned as "preloads" in the PR) are rendered outside of <html> in the server, and inside of <head> in the client.

<script src="/static/js/client2.chunk.js" async=""></script>
<script src="/static/js/client3.chunk.js" async=""></script>
<script src="/static/js/client8.chunk.js" async=""></script>
<script src="/static/js/client7.chunk.js" async=""></script>
<script src="/static/js/client6.chunk.js" async=""></script>
<script src="/static/js/client0.chunk.js" async=""></script>
<script src="/static/js/client4.chunk.js" async=""></script>
<script src="/static/js/client1.chunk.js" async=""></script>
<script src="/static/js/client9.chunk.js" async=""></script>
<!DOCTYPE html>
<html lang="en">
    <head>

@eps1lon
Copy link
Collaborator Author

eps1lon commented Feb 17, 2024

Without the fix from #28353 I do get hydration mismatches

Could you clarify how this manifests other than having to manually inspect the produced HTML? I get no console warnings which you'd usually get for hydration mismatches.

@unstubbable
Copy link
Contributor

unstubbable commented Feb 17, 2024

Without the fix from #28353 I do get hydration mismatches

Could you clarify how this manifests other than having to manually inspect the produced HTML? I get no console warnings which you'd usually get for hydration mismatches.

That's strange. When I check out 4a54e8a (so before the fix), I get the expected console errors.

rm -rf build ./node_modules/.cache && FAST_REFRESH=false yarn dev:

Screenshot 2024-02-17 at 16 43 21

rm -rf build ./node_modules/.cache && FAST_REFRESH=false yarn start:

Screenshot 2024-02-17 at 16 45 36

@unstubbable
Copy link
Contributor

For what it's worth, even with the console errors, and the "Hello World" expectation that was added later, I can't get the tests to fail consistently. Only when I add await page.reload(); after await page.goto('/'); it fails consistently (sometimes with two sets of errors though). Hopefully there's a better fix for this flakiness.

@eps1lon
Copy link
Collaborator Author

eps1lon commented Feb 18, 2024

Can you post the exact instructions how you get the fixture running for you on a fresh clone?

@unstubbable
Copy link
Contributor

unstubbable commented Feb 18, 2024

With the following steps I got the fixture running on a fresh clone:

  • git clone https://github.com/facebook/react.git
  • cd react
  • yarn
  • RELEASE_CHANNEL=experimental node scripts/rollup/build.js --type=NODE_DEV,NODE_PROD,NODE_ES2015,ESM_PROD
    (Because I'm not patient enough for a full build, and I don't know a better way to do this.)
  • cd fixtures/flight
  • yarn
  • adjust the flight package.json because of the custom build step:
    diff --git a/fixtures/flight/package.json b/fixtures/flight/package.json
    index 3d4574778..d33affd88 100644
    --- a/fixtures/flight/package.json
    +++ b/fixtures/flight/package.json
    @@ -64 +64 @@
    -    "predev": "cp -r ../../build/oss-experimental/* ./node_modules/",
    +    "predev": "cp -r ../../build/node_modules/* ./node_modules/",
  • FAST_REFRESH=false yarn dev

And with that, I got a running flight fixture, strangely now without any hydration mismatches. 🙄
Please don't ask me what the difference is to my other clone where I do get the hydration mismatches. 🤷‍♂️

@eps1lon
Copy link
Collaborator Author

eps1lon commented Feb 18, 2024

FAST_REFRESH=false yarn dev

I was missing that bit. Fast Refresh randomly starts working after a couple of failed yarn build && yarn dev.

@eps1lon eps1lon marked this pull request as ready for review February 18, 2024 15:09
@unstubbable
Copy link
Contributor

unstubbable commented Feb 18, 2024

And with that, I got a running flight fixture, strangely now without any hydration mismatches. 🙄 Please don't ask me what the difference is to my other clone where I do get the hydration mismatches. 🤷‍♂️

Ah, I didn't realise that #28353 was merged into main. That explains why the hydration mismatches are gone now.

Copy link
Contributor

@unstubbable unstubbable left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what it's worth, even with the console errors, and the "Hello World" expectation that was added later, I can't get the tests to fail consistently. Only when I add await page.reload(); after await page.goto('/'); it fails consistently (sometimes with two sets of errors though). Hopefully there's a better fix for this flakiness.

@eps1lon Since this is not addressed yet, I believe there will be false positive test results whenever a console error may appear due to some changes in the code base.

@eps1lon
Copy link
Collaborator Author

eps1lon commented Feb 18, 2024

I believe there will be false positive test results whenever a console error may appear due to some changes in the code base.

The idea is that we prevent these from creeping in since that's an error. console.errors are not false positives. If they are expected, they can be added to the assertion.

I'll try the page.reload(). Thank your for the tip

@unstubbable
Copy link
Contributor

I believe there will be false positive test results whenever a console error may appear due to some changes in the code base.

The idea is that we prevent these from creeping in since that's an error. console.errors are not false positives. If they are expected, they can be added to the assertion.

I meant "false positive test results" as in there might be a successful test despite console errors occurring, due to the test exiting before the calls could have been collected.

@unstubbable
Copy link
Contributor

unstubbable commented Feb 18, 2024

For what it's worth, even with the console errors, and the "Hello World" expectation that was added later, I can't get the tests to fail consistently. Only when I add await page.reload(); after await page.goto('/'); it fails consistently (sometimes with two sets of errors though). Hopefully there's a better fix for this flakiness.

@eps1lon Since this is not addressed yet, I believe there will be false positive test results whenever a console error may appear due to some changes in the code base.

I tested the latest version of this PR again, but without d37ca84, and now I do get consistent test failures, as expected. So maybe there's no need to change the test, after all.

@eps1lon
Copy link
Collaborator Author

eps1lon commented Feb 21, 2024

Didn't detect any flakiness while running locally so let's see how CI treats it.

@eps1lon eps1lon changed the title Add smoke test to flight fixture Add smoke test for flight fixture Feb 21, 2024
@eps1lon eps1lon merged commit 81d2a51 into facebook:main Feb 21, 2024
37 checks passed
@eps1lon eps1lon deleted the test/fixture-flight branch February 21, 2024 22:47
EdisonVan pushed a commit to EdisonVan/react that referenced this pull request Apr 15, 2024
bigfootjon pushed a commit that referenced this pull request Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed React Core Team Opened by a member of the React Core Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants