π Enable babel transpiling of react-native as well #1193
Conversation
This fixes the code coverage github action.
Without this change, we were getting the error
```
i FAIL www/__tests__/DateSelect.test.tsx
β Test suite failed to run
SyntaxError: /private/tmp/e-mission-phone/node_modules/react-native/Libraries/vendor/emitter/EventEmitter.js: Unexpected token, expected "]" (39:5)
```
The last successful run was from Oct 17.
The first failed run was from Oct 23.
We have not made any changes to the react-native components that we directly
import since Sept 2024. However, we use a carat semver, so we will pull newly
released minor versions. One of our dependencies bumped up the version of RN
that they use, and released a new minor version, which broke this.
After fruitlessly searching around for a root cause (as documented in the PR
comments), since we import a lot of components and it was laborious to check
when each of them have been updated, I did a brute force search in GitHub for
this error and found both the same issue
facebook/react-native#48228
and a fix that worked
facebook/react-native#48228 (comment)
I am surprised this has not been reported widely, but I guess it is fairly new!
Thanks to @Basil-Code for the suggestion!
|
I thought this would be a simple fix so I didn't file an issue to track progress. |
|
Similar issues were apparently caused due to not using the correct version of node But bumping up node to 22.12.0 did not fix anything |
Codecov ReportAll modified and coverable lines are covered by tests β
Additional details and impacted files@@ Coverage Diff @@
## master #1193 +/- ##
==========================================
- Coverage 29.98% 29.78% -0.20%
==========================================
Files 123 123
Lines 4933 4955 +22
Branches 1091 1142 +51
==========================================
- Hits 1479 1476 -3
- Misses 3454 3477 +23
- Partials 0 2 +2
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
We have not made any changes to the react-native components since Sept 2024. Did this break around that No, the last successful run was from Oct 17. The most likely cause would be an underlying library change, but we have pinned dependencies. Where does EventEmitter.js come from anyway? It is (c) Meta, and is in the Nope, RNWeb just uses the EventEmitter. Aha! the So we do have to focus on the react-native package. We do note that the versions are specified with a carat Alas, since I don't have an older instance of the "serve" so I can't compare to see what the pinned versions were earlier. But I do note that we have |
|
I do see the error RNtesting library comes directly from this project We get React native testing library was released Nov 27. What if we forcibly downgrade it to 12.3.0? downgraded, still failing |
|
Also found https://dev.to/bytebodger/how-i-fixed-the-unexpected-token-error-in-jest-4o1j and tried to change the command to |
Running the test using `npx jest` instead of `npm run test` means that passing in command line arguments to jest needs to either be coded in two places, or that jest would be potentially invoked inconsistently. This changes the invocation to use `npm` so that the command line args (if any) can be passed in to a single location. e-mission#1193 (comment)
We use `^` versions for our dependencies, which means that any compatible minor version could be pulled. However, we recently ran into an issue (e-mission#1193 (comment)) in which a change to a minor version broke our tests. Sifting through all our dependencies to find the ones that were bumped, and which dependencies they bumped in turn is time consuming. For example in the issue above, the dependency that caused the break was `react-native`, which we don't include directly in our project. One option to identify changes would be to check the `package-lock.json`, but unless we are constantly reinstalling npm, we won't necessarily know what changed around the time that the tests broke. Uploading the `package-lock.json` from runs allows us to see the versions from before and after the break and narrow down the potential changes.
We use `^` versions for our dependencies, which means that any compatible minor version could be pulled. However, we recently ran into an issue (e-mission#1193 (comment)) in which a change to a minor version broke our tests. Sifting through all our dependencies to find the ones that were bumped, and which dependencies they bumped in turn is time consuming. For example in the issue above, the dependency that caused the break was `react-native`, which we don't include directly in our project. One option to identify changes would be to check the `package-lock.json`, but unless we are constantly reinstalling npm, we won't necessarily know what changed around the time that the tests broke. Uploading the `package-lock.json` from runs allows us to see the versions from before and after the break and narrow down the potential changes.
We currently run tests and check code coverage in the same workflow, and fail if the code coverage goes down. But our current coverage is fairly limited (< 20%) so we have a lot of failures from changes to code that currently does not have any tests. Let's still check the code coverage for the patch, but disable it for the project, so it doesn't mask errors in the tests. We should not have to enable this since https://docs.codecov.com/docs/common-recipe-list#set-project-coverage-checks-on-a-pull-request > By default, Codecov will only show git diff coverage checks on a PR. > "Project coverage" checks and "project coverage" reporting is not available for Private Repos on the Codecov team plan. > For all other private repos, and for all public repos, here's how you can also show project coverage checks on a PR. But it is clearly failing and is the only test failing, so let's make the change anyway. Once we improve coverage to cover more areas, we can re-enable this.
shankari
force-pushed
the
fix_javascript_tests
branch
from
2c975b8 to
e9abaee
Compare
|
@JGreenlee for visibility |
This fixes the code coverage github action.
Without this change, we were getting the error
The last successful run was from Oct 17.
The first failed run was from Oct 23.
We have not made any changes to the react-native components that we directly import since Sept 2024. However, we use a carat semver, so we will pull newly released minor versions. One of our dependencies bumped up the version of RN that they use, and released a new minor version, which broke this.
After fruitlessly searching around for a root cause (as documented in the PR comments), since we import a lot of components and it was laborious to check when each of them have been updated, I did a brute force search in GitHub for this error and found both the same issue
facebook/react-native#48228 and a fix that worked
facebook/react-native#48228 (comment)
I am surprised this has not been reported widely, but I guess it is fairly new! Thanks to @Basil-Code for the suggestion!