As promised, here’s the recap from the last FWG meeting, held on 2022-03-10.
Video (only I had the video on, so it looks like a huge monologue. I assure you it wasn’t. :P)
- Chat log
Got you covered, but the text version is not that short, either.
Node 16 upgrade
@Binod_Pant_2U started by giving an overview of the Node 16 upgrade. We have at least two contributors helping, some repos already have Node 16 (prospectus: thanks @bseverino!). In the sheet we can see the repos that already merged. Note that a few repos do not need to acted upon, such as edx-platform (at least until all the other repos are migrated). Please continue to spread the word to get more help: we’re targetting March 30 as a completion point for the first phase. (April 9th is the cutoff point, for Nutmeg, so yeah, that’s a good date). The second phase will be relatively quick.
Some MFEs are running into “interesting” issues. In particular, when upgrading dependencies. Such is the case with the frontend-app-library-authoring upgrade ticket, which tCRIL has taken on. (Thanks, @cmuniz!)
The question of whether to continue supporting Node 12 came up. It seems safer to do so, for now, though whichever MFEs end up in Nutmeg need to either support Node 12 or Node 16. In discussing this, we noticed that the Gradebook MFE (one of the Tutor defaults) was not being considered for the Node 16 upgrade… so we added it in.
MFEs and releases
Next, the question of which MFEs should be part of Open edX releases came up. In other words, “what bar must MFEs pass before they’re considered for inclusion in the next release?” It was suggested that this be asked of the Build-Test-Release working group, which is exactly what I’ll do at their next meeting.
@AdamStankiewicz brought up that there is in fact a page that defines the concept of “done” for an MFE, and we should maybe use that as a starting point.
@ghassan in turn asked what should happen when an MFE completely replaces a pre-existing Open edX feature. It was suggested that the pre-existing feature must go through the official deprecation process (aka OEP-21), a process which in this particular situation might be extended so that the removal of the original feature can only happen if the replacement MFE is actually accepted (by the BTR?) into the next release after the feature is removed.
A heisenbug in frontend-build
@AdamStankiewicz asked for our help with a particularly interesting frontend-build issue that affects some MFEs, but not others. There were no immediate takers, but @ghassan said he might take a look, and I offered to solve it if at tCRIL we hit the problem as part of the library-authoring Node 16 upgrade.
FWG presence in the conference
There was some quick discussion around frontend working group participation in the upcoming edX Con. @AdamStankiewicz noted he had submitted a talk, then I made the point that there will be time during the conference dedicated for working groups to meet: we should make use of it!
I Asked Adam about the MFE workshop he co-organized in the 2019 conference. He reports it was a fruitful one, albeit hampered by bandwidth issues in the venue (as often happens). There won’t be one in this year’s conference, but perhaps we could get together to host another one next year.
How should Paragon component deprecation be handled?
In a late but important entry added to the agenda, @AdamStankiewicz asked: what is an acceptable way to handle Paragon component deprecation?
A rather long discussion ensued, but the gist of it is that:
- There is a (rather neat) list of Paragon components, and ones that are deprecated are easy to make out, as they’re listed in grey.
- In an even neater turn of events, there is also a list of which Open edX repositories use each component - which helps explain why none of the deprecated components, some of which have been deprecated for years, have actually been removed.
Modal, for instance, is still used pretty much across the board.
- For the triple play, we found that a component’s doc page, if deprecated, also lists what it was replaced with. (See the Checkbox, for instance.)
- But whatever happens, though:
- Deprecations (i.e., the marking of components as such) should ideally be announced as soon as they happen, including with a friendly heads-up in the forum - which @AdamStankiewicz agreed to do.
- Use of deprecated components should come with a build-time warning. We found that there are indeed warnings in place, but we’re not sure if they’re shown at build- or run-time. (Possibly even just shown in the browser console, which would be less than ideal.)
- Removals, if they ever actually happen, should be announced with as much lead time as possible.
The next meeting will be held on Thursday, March 24th at 16:00 UTC (Timezone converter). The draft agenda can be found on this issue.