The Big Frontend Working Group Meeting Thread

Working Groups Frontend
1

Folks that have been attending the frontend working group meetings are already aware of this, but as of the last one a couple of things changed:

  • Meetings are now to be held bi-weekly on Thursdays, at 16:00 UTC, in this Zoom meeting room.
  • If you prefer to subscribe to a calendar (an easy way to become aware of changes), we have a new one, this time hosted under the tCRIL organization. (Discussed this with @djoy, and we thought this would be best.)
  • In a direct steal from the Community Working Group playbook, we’ll now have a github issue and two forum posts in this thread for each meeting: this is the invite post, after the meeting we’ll post a recap, and this is the first GH issue.

That’s it! See you later on today. :slight_smile:

2

As promised, here’s the recap from the last FWG meeting, held on 2022-03-10.

  • Agenda
  • Video (only I had the video on, so it looks like a huge monologue. I assure you it wasn’t. :P)
  • Chat log

TLDW?

Got you covered, but the text version is not that short, either. :stuck_out_tongue:

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.

Participants

Next meeting

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.

4 Likes
3

It came to my attention that there was some confusion regarding the time of our meeting. When I inherited the role of host, I automatically recreated it in the time it was usually held… but in UTC. This meant that when the US entered DST last week, the meeting time changed for some participants.

I’m a firm proponent of using UTC for all synchronous events in a global context (because then the average participant only has to be aware of their own country’s DST policy, as opposed to potentially having to deal with two) and am not suggesting we change that, but we can, of course, change the UTC time of the meeting any time we want as long as there’s consensus. :slight_smile:

So here’s the poll:

Make sure to first pick your timezone, then paint any times (not just one!) during the week that work for you. Also make sure to give a name we’ll all know you by, to help keep track of who’s voted.

Be aware that:

  • This will affect our next meeting, already
  • We’ll be agreeing on a time in UTC, so if you want to avoid having to do this again a few months down the road, pick times that accomodate your country’s DST fluctuations. (I.e., don’t pick a time that will land the meeting squarely during your lunch hour next time DST starts or ends.)

Thanks!

4

It looks like the first available time that a majority of people (that voted) can attend is:

15:00 UTC (Result from here.)

This means today’s meeting will be moved an hour earlier from its previous time slot of 16:00 UTC. I have updated the calendar accordingly.

PS: I’ll leave the poll running until the subsequent meeting. It’s still possible for more votes to change the outcome.

5

Recap from the FWG meeting on 2022-03-24.

TLDW

Node 16 upgrade

As usual, we started with an upgrade to the Node 16 upgrade effort by @Binod_Pant_2U, where we took a look at The Sheet. Things are moving along nicely, and effort is being focused on the repos targetted for Nutmeg. In doing so, we identified two repos that were missing from the list: frontend-component-header and frontend-component-footer.

An issue was raised of whether to regenerate a given MFE’s package-lock.json using Node 16’s new dependency format/model. The consensus was that this should wait until “Phase 2” of the upgrade is under way, where Nodes 12 and 14 are to be removed from the test matrix. This will require frontend-* library repos (frontend-platform, build, etc) to relax their constraints, so that all dependency versions in use are encompassed.

Recap of the heisenbug in frontend-build

We revisited that frontend-build issue. It seems nobody was able to reproduce it. @AdamStankiewicz volunteered to get more information on the reference to NewRelic in the description, and also to check whether the issue is actually still happening.

A possible dependency licensing issue

A user in the forum brought our attention to the fact that a frontend-build dependency, @newrelic/publish-sourcemap, does not carry a license that explicitly allows redistribution. (Issue here.) One possible technical solution was suggested by @AdamStankiewicz: to use optional dependencies and conditional imports, with the drawback that this would require any and all repos using this dependency to make changes to their imports. Another was to, instead of relying on that package, to use the NewRelic API directly.

To try and avoid a needless technical rabbit hole, it was agreed that first we should find out if redistributing that library is allowed, or not.

Update on MFE gating proposal

There is some progress on the MFE gating proposal: there were no objections raised to the idea, so far, either by the BTR, Community, or Frontend working groups. The ball is now on my court to write the actual proposal in a reasonable place.

There was some discussion on how this proposal will affect Nutmeg. In short, it won’t, and it doesn’t need to. The idea is to formalize a process that, in practice, already happens: the BTR group already vets MFEs. What the proposed process will do is make all other parties aware of the bar MFEs need to pass, so that they can spend time on getting MFEs ready up front - instead of waiting for a veto.

A look at the board

We took a look at the board, and only one thing jumped out that hadn’t been discussed before: one ToDo issue was actually done, so it was marked as such.

Participants

Next meeting

The next meeting will be held on Thursday, April 7th at 15:00 UTC (Timezone converter). The draft agenda can be found on #93 on the board.

2 Likes
6

Recap from the FWG meetings on 2022-04-07 and 2022-04-21 (missed the first one, so this is a conflated version).

TLDW

Node 16 upgrade

The Node 16 upgrade has been moving steadily along. Sadly, @Binod_Pant_2U left us, so I volunteered to head the effort. Phase 1 of the upgrade is complete as far as Nutmeg and Tutor are concerned, which is to say: if the Tutor MFE image is upgraded to Node 16, things should Just Work :tm:.

There is no deadline for Phase 2 (where we remove Node 12 and 14 support), at the moment, except for the expectation that it’ll be done for all relevant MFEs by Olive.

Works in progress

I’m excited to report that some of the issues raised by the MFE survey I’ve been engaged in (thanks for all replies so far!) are already being tackled by the community:

and

We also got a couple of interesting proposals from 2U that were approved pretty much unanimously:

They’re far from complete, but we intend to keep track of them.

What’s up with the Library Authoring MFE?

@Daniel_Quiroga asked for an update on the status of the Library Authoring MFE, and I summed it up as follows:

The MFE itself is still a work-in-progress, and definitely not ready for production. tCRIL is engaging in some spring cleaning, but not adding new features.

The real sticking point with Libraries v2, however, is that there is still no defined way to include library content in existing courses. You can author content, the blockstore backend works (as long as you know how to deploy it), and you can even use the content via LTI, but you definitely can’t use it in courses, yet. So the feature has limited value for most users.

New bug

@dcoa reports a new bug report over in the Overhang forum related to a new version of studio-frontend that apparently affects file uploads. The workaround seems to be pinning it to an ealier patch, but we’re still trying to get a better understading of why the breaking change was made in the first place. First, we need to find out who owns that, though. @AdamStankiewicz, any clue? :slight_smile:

Frontend discussion at the conference?

Aside from @Daniel_Quiroga and me, it’s looking like there won’t be many regular FWG attendees at the conference, so I did not schedule a specific get-together on Friday the 29th. However, since much of our frontend discussion happens in the context of deploying MFEs, I suggest we meet with the BTR group in room D-115 on Friday, and split off if there’s enough interest.

Participants

The following were present for either one or both previous meetings:

Next meeting

The next meeting will be held on Thursday, May 12th at 15:00 UTC (Timezone converter). The draft agenda can be found on #98 on the board.

To be clear, the next meeting is being pushed back a week from May 5th, when it would otherwise have been held. This is simply because I’ll be taking a week off after the conference, and so far I haven’t found somebody to replace me as host.

1 Like