React 17 upgrade

[abdullahwaheed]

Abstract

Most of the MFEs of edX are currently using React JS v16. In order to use latest React JS, we are planning to upgrade React JS to v17.

Context & Background

React 17 doesn’t add any new developer-facing features, so its upgrade might not cause any breaking changes. Our end goal is to upgrade React to v18 but v18 no longer support enzyme, so we are upgrading to React 17 and then we’ll migrate from enzyme.

Scope & Approach

In each MFE/library, with React, React DOM 17 upgrade, we may need to upgrade following

• in case of Typescript, install @types/react@17.0.0
• If you are using React Testing Library, you would want to be under 12.1.5, which is the latest version that supports React < 18.
• Replace enzyme-adapter-react-16 with @wojtekmaj/enzyme-adapter-react-17 since enzyme doesn't provide support for react 17.
• react-test-renderer should also be updated.

Value & Impact

After this upgrade, we'll get one step closer to use latest React JS across the board

Milestones and/or Epics

edx/upgrades#390
React 17 Upgrade

Named Release

Q

Timeline

Tentative End Date: July 31, 2023

Proposed By

2u

Tasks

Tasks

Beta Give feedback

1. Create a roadmap issue in the platform-roadmap repository
2. Add this checklist to the roadmap issue's description
3. Add the "maintenance" label to the roadmap issue
4. Add the roadmap issue to the Backlog column of the Open edX Roadmap project
5. Set appropriate values for the roadmap project's custom fields for the issue (especially "Proposed by", "Platform map - Super Level", "Strategy", and "Type")
6. Set an appropriate release milestone for the roadmap issue
7. Add an explicit target completion date to the roadmap issue description, and explain there why it was chosen
8. Select an orchestration team
9. Name the orchestration team in the roadmap issue description
10. Create a repo health check to identify most/all of the repositories impacted by the upgrade (and ideally, whether or not the upgrade is believed to be complete)
11. Create a new value for the "Project" field in the Maintenance project board for this upgrade project
12. Create a new view in the Maintenance project board that filters down to only the issues in this upgrade project
13. Create an issue in each impacted repository for the upgrade, and add it to the Todo column of the Maintenance project board; specify at least the "Project" and "Source" field for each issue (and "Owner" also if you're a 2U or Arbisoft employee)
14. Create a task list in the roadmap issue listing all of the impacted repository issues
15. Create a page under Upgrades in Confluence for documentation related to the upgrade
16. Add a link to the Confluence page from the roadmap issue
17. Add a link to the roadmap issue from the Confluence page
18. Document in a Confluence child page the changes believed to be most problematic and/or interesting about the upgrade
19. Create a ticket to determine the appropriate amount of automation (codemods, repo health checks, etc.) to create for the upgrade
20. Perform the automation discovery work and write upgrade instructions for all project participants in a Confluence child page
21. Link to the upgrade instructions from the roadmap issue
22. Send an announcement of the upgrade, asking code maintainers to read the upgrade instructions and select an upgrade service level for each impacted repository in its corresponding issue
23. Create issues in public-engineering for each external dependency which still needs code changes and/or a release to support the upgrade
24. Add the "help wanted" and "maintenance" labels to each public-engineering issue created above
25. Add each public-engineering issue created above to the Maintenance project board
26. Set appropriate values for the Maintenance project board custom fields for each added public-engineering issue
27. Ask the Open edX developer community (especially Core Committers) for assistance with the added public-engineering issues
28. Create Build-Test-Release Working Group and/or 2U SRE tickets if they will need to do work for the upgrade
29. Complete and update all of the created implementation tickets
30. Deploy all of the updated services
31. Update the support windows spreadsheet to correctly indicate the version now used
32. Announce the successful completion of the upgrade
33. Make sure any deployment instructions make it into the release notes of the next Open edX named release (collaborate with the BTR WG)
34. Remove any CI matrix entries for no-longer-supported versions of the dependency
35. Remove the Maintenance project board view/tab created for the upgrade
36. Stop running repo health checks related to the upgrade which are no longer relevant
37. Schedule and run a retrospective meeting about the upgrade
38. Update the Upgrade Project Runbook based on retrospective findings, if appropriate
39. Mark the roadmap issue for the upgrade as complete
40. Move the root Confluence page for this upgrade’s docs under Past Upgrades
41. Ticket work to replace or take over dependencies which were found during the upgrade to be inadequately maintained

[github-actions]

Thanks for your submission, @openedx/open-edx-project-managers will review shortly.