Looks like the experimental Codex styles are working as intended.

Hey @Jdlrobson – you can set the Minerva skin to use the "experimental" Codex theme and Codex components in Minerva will start respecting the values of the CSS variables.

In T350790#9580337, @Jdforrester-WMF wrote:

No, it won't be as useful. The request here is for the file to be included like it is for many of our other libraries. I'm surprised how much push-back this is getting.

This is an old task and I don't know much about the context here. Is this problem still happening?

In T356465#9560909, @Lofhi wrote:

In T356465#9522569, @AnneT wrote:

I'm pretty convinced that we should not worry about this. Codex is the design system for Wikimedia, so I think it's okay to limit ourselves, especially given our limited resourcing, to the themes/modes for Wikimedia products.

Do you consider web community projects using Codex to be "outside of WMF projects"?

Hi @Lofhi – we (the WMF Design System Team) don't have a formal policy around Vue updates but our intent is to periodically bump the version of Vue used in both MW Core and in Codex to the latest stable version. This is something we expect to do maybe 2-4x per year. We pin to exact versions (no ^) for runtime dependencies like this.

@Catrope if you update to use this Codex patch to produce the experimental output, you'll get an RTL experimental stylesheet.

I'm working on an updated patch for this that does not require changes to the token source files.

In T350056#9540716, @Catrope wrote:

In T350056#9539176, @egardner wrote:

I am concerned that introducing a bunch of new dependency relationships between ResourceLoader modules (which would not otherwise exist)

I think that if this feature is merged, it should come with guidelines for when it's appropriate to use it. Off the top of my head, that would be:

• Dependencies between modules in the same extension/skin/feature
• If we create a module in MW core with common/"core" Codex components that we expect almost every feature will use, then it would be appropriate for any Codex-using module to depend on that "core components" module

In T350056#9539661, @CCiufo-WMF wrote:

In T350056#9539176, @egardner wrote:

I can't speak to how much risk this change introduces, but I don't think we should assume this would be temporary. We decided to take on this task with the idea that it would exist until there's a clear case for perfect deduplication.

I've closed this task in favor of https://phabricator.wikimedia.org/T357475

I want to surface some engineering discussion about these patches here in Phab for a wider conversation. Here's a Gerrit comment I posted on the final patch in @Catrope's patch chain that implements this feature:

Per yesterday's discussion, I think the best solution is to simply archive/decommission the Vuetest extension all together. Everything that we created this extension to do has been surpassed (or will be surpassed) by something else:

Style Dictionary provides a built-in transform that can take color tokens (with value in any format – hex, RGB(A), hsl, etc) and add a set of attributes for all formats. The built-in transform requires CTI organization but it would be simple to re-implement our own version of this with a matcher appropriate for Codex.

I think that this is another situation where we could update our "basic support" baseline somewhat and avoid having to resort to complex workarounds and hacks.

Hey @taavi, I posted a patch to PageTriage that fixes this issue. I resorted to a "brute force" solution where I simply scrapped the old package-lock.json, updated the dependencies manually, and then ran npm install to re-create it. If that's not an approach that you want to take, hopefully the patch (and it's accompanying package-lock.json file) will be useful in further debugging here.

It looks like the master branch of PageTriage still lists very old Codex versions in package.json:

Do you mean getCodexFiles (as opposed to `addComponentFiles)?

In T353172#9504471, @Catrope wrote:

Question: Do we want to include fallbacks (var(--color-primary, #36c)) in these new files?

We should explore whether we can work around this by:

• stacking name transforms, despite the Style Dictionary docs saying that it doesn't make sense to do this; or
• writing a custom name transform that applies the built-in camelCase transform but also avoids this collision; or
• filtering out the option tokens / theme tokens using Style Dictionary's built-in filter feature (and somehow avoiding/suppressing the other warnings that would result from that)

In T338184#9480246, @bmartinezcalvo wrote:

@egardner design sign-off done. Just a couple of corrections:

1. Update the alt text in the new Interaction States image: "Interaction states of Accordion for both collapsed and expanded: default, hover, active, and focus."
2. Could the focus state be visible just after pressing the Accordion as we do with Button to avoid the active state being visible at the same time as the focus?