I am still struggling to fully grok things… Apologies if this is already addressed somewhere!
I have been postponing really implementing features and getting set up whilst waiting for ulmo to drop, so I can make sure to work from “the future”. From what I have been seeing everywhere and since at least the beginning of the year, design tokens is the future and all the MFEs are being migrated to that (frontend-base too, but that doesn’t appear to have been pushed very far yet?). My impression was that it would even take some hacking to get the newly cut versions (mfes and edx-platform at least) to work with old-style styling.
Hence my assumption that the new version of tutor would be migrating indigo to design tokens, if it weren’t already done. I couldn’t see anything suggesting that in the commit logs (maybe I missed it?). I did, however, see https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4706533406/Proposal+Make+Indigo+the+default+Open+edX+Theme . According to that, indigo doesn’t use design tokens, and… won’t (cf, Regis Behmo’s comments)? As indigo is the default in tutor and tutor is now the “officially supported” way to deploy openedx, the vast majority of non-bigly-invested organisations will probably just use the default tutor theme. Thus it would seem that, at least for ulmo, most new actual openedx instances won’t be using design tokens. tutor-mainseems to be working, so my assumption about the old-styling appears to be wrong (I didn’t look in enough detail to see whether there were any hacks to make non-design tokens work).
Thanks! The main question is whether it’s optional going forward. I spent several hours combing through the various bits of documentation and repos and only after that posted here.
If there is massive resistance by most users (and by “users” I mean operators) not actually using an implementation of design tokens, that would appear problematic, and it might get reconsidered/paused like module federation. From my point of view as a non Tutor user, the fact that Tutor is the only officially supported method for most operations (build, deploy, etc.) task means that if Tutor doesn’t implement something directly, it gets phenomenally difficult. The easiest method to understand something is to retro-engineer how Tutor does it, but if Tutor doesn’t implement it, the onboarding cost skyrockets immediately. Even the tutor-contrib-paragon plugin currently only supports tutor>=19.0.0,<21.0.0, so it’s not guaranteed I can retro-engineer from that.
Design tokens is the only theming system from ulmo and beyond. From the link I posted:
There will be no overlap between the old theming system and Design Tokens, so site operators will need to prepare for the changes in advance of the Ulmo release.
I’d like to add a bit of clarification here with regards to what “the old way” and “the new way” are, as well as what will and will not work going forward:
“The old way”
Brand packages define styles using scss, referencing scss variables defined in Paragon. Brand package scss is combined with Paragon scss at build-time.
“The new way”
Brand packages define styles using design tokens. Brand packages use the Paragon CLI to transform/compile those design tokens into css. Compiled brand package css includes overrides for Paragon css variables.
What will work
Brand packages that reference/override Paragon css (by defining styles with tokens and using design tokens to generate css)
What will also “work”
Brand packages that reference/override Paragon css (without defining styles using tokens or using design tokens to generate css)
It is highly recommended that brand packages define styles using tokens. Generating (or manually writing) brand css is not documented, and changes to css variables (without changing the Paragon tokens) are not considered breaking style API changes.
What will not work
Brand packages that reference/override Paragon scss variables (as they no longer exist in Paragon >=23)