One exciting thing: it feels like we’re getting closer and closer to having most of the UI implemented in MFEs. At some point, we’ll be able to remove all the static assets from edx-platform. As a test just now, I commented out the 14 commands in Tutor’s openedx Dockerfile that are related to static assets or Node.js, and the time it takes for tutor images build openedx dropped from 10 minutes to 30 seconds. And it runs fine, and works well with the MFEs - the main missing piece is that XBlocks cannot render in the learner MFE without the iframes/assets from the LMS. So it’s not quite usable yet. But, if we can solve that one thing (rendering XBlocks) and probably also implement the Instructor Dashboard in an MFE, then I think we can start to offer a “no legacy UI” build of Tutor Nightly that has all that stuff disabled and builds the platform much much faster.
Yes, the MFEs are slow to build, but at least if you’re only working on the platform, or only working on one MFE, you can rebuild just the thing you need much faster. (Also, MFEs aren’t inherently slow to build! We’re just locked into old tooling at the moment - it’s webpack, SCSS, and babel that are slow. With alternatives like SWC, Vite, Lightning CSS, etc. complete builds of even large MFEs can take under a second.)
Yeah, I understand but I don’t think that feeling is true. I’ve been using only the tutor nightly devstack for the past two years and I feel like I rebuild (via tutor dev launch -I) quite rarely, actually. Most of the time I can pull the latest build of edx-platform and it will run fine without a rebuild; or if I need to I can run migrations or rebuild static assets to fix a specific update requirement. It’s usually only if there are major changes to the system or python dependencies that I need to rebuild the images completely.