feat!: Upgrade to TypeScript 6 & 7

[bradenmacdonald]

I guess we're not using this with frontend-base, but I'd still like to get the Authoring MFE upgraded to TS6+.

As I understand, I need to:

• upgrade this package and publish it as v2
• Upgrade frontend-build to pull in new edx/typescript-config and ts-jest
• Upgrade frontend-platform to pull in new frontend-build and bump react-intl to fix formatjs dependency on TS 5
• Then non-frontend-base MFEs should be able to use TS6 ? This also unblocks newer versions of oxlint/tsgolint

Doing dependency upgrades like this across so many repos is a big pain, especially with semantically-released making the package.jsons uninstallable and npm link not installing bin scripts as normal. So it's very difficult to test anything until each package is published to NPM. I do hope frontend-base solves this.

[openedx-webhooks]

Thanks for the pull request, @bradenmacdonald!

This repository is currently maintained by @openedx/committers-frontend.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[bradenmacdonald]

@arbrandes Could you please take a quick look at this?

I'm also not sure why github says a tests CI check must pass. I have added some new CI tests here, but this repo's CI infrastructure is extremely outdated.

[arbrandes]

@bradenmacdonald

I do hope frontend-base solves this.

Making local changes to cross-cutting libraries like this one (including frontend-base itself) and testing them is indeed foreseen and supported when using https://github.com/openedx/frontend-template-site for development. (Getting it to work required us to resort to NPM workspaces and then Turbo to do the builds in the proper order, but it does work.)

But since we're on the subject, I've been asking these whenever I see major upgrades in frontend-platform land:

1. Can we do it in frontend-base first? As in, let's treat it as the org's "master": new things go in there first, then are optionally backported to frontend-platform if we think it makes sense.
2. Can we live without it for a few more months, until we're all in frontend-base land? (As in, Xylon.)

[bradenmacdonald]

Can we do it in frontend-base first? As in, let's treat it as the org's "master": new things go in there first, then are optionally backported to frontend-platform if we think it makes sense.

Definitely, but I took a quick stab at it and it's unfortunately non-trivial. To upgrade typescript, we need to first upgrade react-intl, which is on v6 but the latest is v10 (!). To upgrade react-intl, we have to get Jest to play nice with ESM, and and make some changes in Paragon as well since it specifies a dependency on react-intl 6.

Can we live without it for a few more months, until we're all in frontend-base land? (As in, Xylon.)

Sure, but my fear is that if we can't do these upgrades now, which should be fairly routine, when we have only 2-3 MFEs, isn't it going to be even harder to do them when we have 12+ MFEs all using frontend-base?

[arbrandes]

if we can't do these upgrades now, which should be fairly routine, when we have only 2-3 MFEs, isn't it going to be even harder to do them when we have 12+ MFEs all using frontend-base?

Probably. But this is the price to pay for consistency across the org's codebase.

However, the hope is that once all apps are consistent, then upgrades - while not necessarily straightforward, like this one - become easy enough to apply across the board once the first example exists. LLMs have to be good for something, right? :)