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

C2LC-575: Update react-scripts to version 5 #317

Merged
merged 6 commits into from
Jan 24, 2022

Conversation

sbates-idrc
Copy link
Contributor

* With the update, ESLint started generating 'no-use-before-define'
  warnings when a class method has a Flow annotation that states
  that the method returns an instance of itself. We use this pattern
  in the CharacterState and ProgramSequence classes. This commit
  adds comments to suppress these ESLint warnings.

* Update the Netlify build to Node 14 (react-scripts version 5 no longer
  supports Node 12)

* Update the GitHub Actions CI build to Node 14 and 16
With the update to react-scripts 5.0.0, flow-coverage-report is failing
with an error similar to this issue filed against flow-coverage-report
on 2021-10-21:

rpl/flow-coverage-report#208
@the-t-in-rtf
Copy link
Contributor

We should discuss in today's meeting, I think we can keep the flow coverage reporting if we simply switch to using flow-coverage-report via npx. In testing with your branch locally, it looks like the coverage reporting still works that way. That seems the least effort and we keep the value of the report.

@the-t-in-rtf
Copy link
Contributor

I see that the CI checks already used npx. Was there an example of a build that failed or output that was incorrect? In local testing with node@14, all function as they did before.

@sbates-idrc
Copy link
Contributor Author

Thanks Tony.

This is the failure that I saw in CI:

https://github.com/sbates-idrc/c2lc-coding-environment/runs/4597242223?check_suite_focus=true

And the issue filed against flow-coverage-report showing a similar failure:

rpl/flow-coverage-report#208

@the-t-in-rtf
Copy link
Contributor

the-t-in-rtf commented Jan 12, 2022

I compared the output of npm audit when run against develop-1.2 and this branch. This pull resolves 9 moderate severity issues, 10 high, and one critical, leaving us with 2 low severity and 8 medium.

It looks like five more medium severity vulnerabilities would be resolved if we updated node-sass, I filed C2LC-578 to cover that work. We still have some vulnerabilities brought in by react-scripts, these will be whitelisted when we work on C2LC-553.

@the-t-in-rtf
Copy link
Contributor

the-t-in-rtf commented Jan 12, 2022

I compared the packed content sizes in the deployed develop-1.2 preview to those in this build, there were no red flags I could find. The updated version ends up producing a few kilobytes more content, but overall the speed seems fine.

package.json Outdated
@@ -7,18 +7,17 @@
"classnames": "2.3.1",
"enzyme": "3.11.0",
"enzyme-adapter-react-16": "1.15.6",
"node-sass": "4.14.1",
"node-sass": "7.0.0",
Copy link
Contributor

Choose a reason for hiding this comment

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

I didn't see that you had updated this already when I commented earlier and filed C2LC-578. If we're already updating, then we should go ahead and update to 7.0.1.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. Thanks.

@@ -60,6 +60,7 @@ export default class CharacterState {
return true;
}

// eslint-disable-next-line no-use-before-define
Copy link
Contributor

Choose a reason for hiding this comment

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

Are there any circumstances in which this check is helpful to us? If not, maybe we should disable the rule rather than adding all these comments.

Copy link
Contributor Author

@sbates-idrc sbates-idrc Jan 12, 2022

Choose a reason for hiding this comment

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

That's a good question. Disabling the rule, would certainly make the code cleaner by not requiring these comments.

I think the rule offers some value but I think not a huge amount. I'll disable the rule and remove the comments. We can always reconsider. But I think minimizing the number of ESLint-specific comments is worthwhile.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've disabled the "no-use-before-define" rule

@the-t-in-rtf
Copy link
Contributor

I left a couple of minor comments, otherwise this looks good.

@sbates-idrc sbates-idrc merged commit 5c0cfa5 into codelearncreate:develop-1.2 Jan 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants