What would I need to do to apply the Indigo theme to the frontend-base version of authn ? Or is this not yet developed ? Does tutor-indigo support enabling the frontend-base version of authn ? Or does it still only support the MFE version ?
The mfe-dockerfile-post-npm-install-authn patch point only works for the legacy Authn MFE. The frontend-base site has an equivalent mfe-dockerfile-post-npm-install-site patch.
It works a bit differently, though, mainly because there is a single frontend-base site for all frontend-base apps. In other words, whatever you npm-install there will be part of the whole dependency tree, not just for that app.
That said, a more efficient way to get the brand package in is to set it so it becomes part of the main npm install step:
hooks.Filters.ENV_PATCHES.add_item(
(
"mfe-dockerfile-pre-npm-install-site",
"RUN npm pkg set
'dependencies.@edx/brand=npm:@myorg/my-brand-package@^x.y.z'",
)
)
Note that in order to support theming of frontend-base sites, the shape of the brand package manifest changed in version 1.3.0. Notably, how the design tokens are exported. See the relevant package.json diff.
As for Indigo, I’m not directly involved with its development, so I don’t know where its frontend-base support ended up, in Verawood. But I did play around with it when building frontend-base into tutor-mfe. I published a modded indigo package (from this branch) that might work (sorry, haven’t tested it in a while) with the frontend-base Authn app if you do:
hooks.Filters.ENV_PATCHES.add_item(
(
"mfe-dockerfile-pre-npm-install-site",
"RUN npm pkg set
'dependencies.@edx/brand=npm:@arbrandes/indigo-brand-openedx@^2.6.0'",
)
)
Your forked package is the only one that got sort of close. Other tutor-indigo/edly-io versions I tried all failed with errors such as
38.11 Module not found: Error: Can't resolve '@edx/brand/light.min.css' in '/openedx/site'
38.11 resolve '@edx/brand/light.min.css' in '/openedx/site'
38.11 Parsed request is a module
38.11 using description file: /openedx/site/package.json (relative path: .)
38.11 Field 'browser' doesn't contain a valid alias configuration
38.11 resolve as module
38.11 looking for modules in /openedx/site/node_modules
38.11 existing directory /openedx/site/node_modules/@edx/brand
38.11 using description file: /openedx/site/node_modules/@edx/brand/package.json (relative path: .)
38.11 using description file: /openedx/site/node_modules/@edx/brand/package.json (relative path: ./light.min.css)
38.11 no extension
38.11 Field 'browser' doesn't contain a valid alias configuration
38.11 /openedx/site/node_modules/@edx/brand/light.min.css doesn't exist
38.11 .js
38.11 Field 'browser' doesn't contain a valid alias configuration
38.11 /openedx/site/node_modules/@edx/brand/light.min.css.js doesn't exist
38.11 .jsx
38.11 Field 'browser' doesn't contain a valid alias configuration
38.11 /openedx/site/node_modules/@edx/brand/light.min.css.jsx doesn't exist
38.11 .ts
38.11 Field 'browser' doesn't contain a valid alias configuration
38.11 /openedx/site/node_modules/@edx/brand/light.min.css.ts doesn't exist
38.11 .tsx
38.11 Field 'browser' doesn't contain a valid alias configuration
38.11 /openedx/site/node_modules/@edx/brand/light.min.css.tsx doesn't exist
38.11 as directory
38.11 /openedx/site/node_modules/@edx/brand/light.min.css doesn't exist
38.11 /openedx/node_modules doesn't exist or is not a directory
38.11 /node_modules doesn't exist or is not a directory
Yours didn’t quite get all the way there. The color gradient somehow disappeared, and the “Register” tab showed back. Still easier to figure out, or maybe I will just directly tweak our fork of the authn app. It would be nice if the frontend-base-authn was more customizable with plugin slots. There is only one slot for it, which isn’t so useful.
If I remember correctly, all I did in that fork was tweak the manifest and build. The CSS is the same as before, which would explain it not working with the new HTML in the Authn app. (This also illustrates one of the things that branding authors need to consider when going to frontend-base apps.)
Indeed! We welcome specific ideas and contributions, as usual.
It seems frontend-base introduces new CSS layers, and it seems that the priority order is reversed, i.e. from top priority to lower priority, we have: paragon, shell, app, site, brand. That seems counter intuitive that the paragon layer has priority over the app layer, which has priority over the site or brand layers. In order to get the styling to apply correctly, I had to introduce CSS code that sits at the paragon layer, i.e.
Note that some of this CSS (the last two items, i.e. #root .layout .bg-primary-400 h1 and #root .layout .bg-primary-400) is code that comes from the app itself, but which does not get applied because the app layer has lower priority than the paragon layer
That doesn’t sound right. The implemented priority should be, in order of higher priority to lower: anything unlayered > brand > site > app > shell > paragon, as documented here.
No stylesheet should declare its own layer: the layering is done by Webpack itself, based on where the stylesheet is coming from. Where are you introducing this? Any customizations should just be in a brand package - which gets high priority via the brand layer - or just unlayered.
That is also not what I observe. It works fine if I define it with @paragon layer in that file. It very briefly shows incorrectly while it loads, but it gets fixed dynamically within a fraction of a second.
Also, this is wrong, apologies. What doesn’t work if it comes too late is the layer order (a fact that bit me when initially implementing the layers). It’s perfectly fine for late-loaded stylesheets to declare themselves to be in a particular layer.
That said, once we get rid of all the !important traps in apps themselves (hope Paragon doesn’t have any), the layers should always work as expected.
Ok, but then there are lots of !importanttags which are not under my control. Those are bugs in the apps ?
Even the @paragon layer defines some !important properties. Exploring the properties through the developer tools, I have to disable three styles for the color of the text, to get the white color I want there, because there are 3 such !important declarators, in
