Here is a list of currently-existing tickets or other outstanding tasks that I think could be considered potential sub-tasks of this. In some cases the original ticket may need to be re-written a bit to match this format.

• Support Vue in Gadgets/Userscripts T313945: potentially high impact because there are a number of community developers who are interested in using new tools in their own work. This task is blocked by a single technical issue (MW's JS validator not supporting newer syntax) that we could probably solve fairly quickly.
• Finalize Vue 3 Migration T289017: finalize migration to Vue 3 (by removing the compat build). Continuing to ship the Vue compatibility build in production has negative performance impacts, so moving all existing Vue projects off of it will deliver a benefit to users. This task may take a while and a lot of the work will need to be done by other teams (WMDE, Structured Data, etc), but DST should probably support and assist in this process.
• Codex Manual Testing Improvements T306180: A lot of the work to improve this process is already done, but might need to be tied together. The VueTest extension (which DST maintains) provides a way to test Codex within MediaWiki (internationalization, interaction with skins, etc), and we have multiple ways to facilitate the use of this extension by QA folks (cloud-based PatchDemo, local docker env, etc). We should just decide which approach is best.
• Craft policy about when/where Vue can be used T248718: Will likely require a facilitated discussion between different teams, but clarifying a policy here will make it easier for other teams to know when and where they can use Vue, Codex, etc.
• Migration of remaining WVUI projects to Codex: Not sure if there is a definitive task for this, but DST can help support the final deprecation of WVUI. This might be a sub-task of the "Finalize Vue 3 Migration" item above.
• Improvements to linter tools for Vue, ES6, etc: Not sure if there is a task for this either, but current eslint-config-wikimedia ruleset for Vue 3, ES6, etc may need to be updated. This helps ensure teams can follow best practices in front-end development without direct involvement of DST
• Distribute CSS-only global styles as part of Codex: As we specify the new design system, there are certain global styles (typographic rules, link styles, breakpoints and grid systems, etc) that may need to be available outside of Codex components (and maybe without JS at all). This could take the form of LESS mixins, CSS stylesheets, or both. Values would still derive from the canonical design tokens. Having these assets available might help us deal with problems that come up in SSR

Another critical thing for the adoption of Codex is usage docs, which are in progress but still need some work. This kind of straddles the line between infrastructure and documentation, but there are a series of important tasks that are more related to the infrastructure of the Codex docs site:

• Document types and constants on the docs site T300154: Some of our usage docs refer to constants or TypeScript types that are declared in the code but not properly documented on the docs site at the moment (e.g. see the menuConfig prop of the Select component—the structure of this prop, which follows the MenuConfig type, is not explained anywhere on the demo page). We will need to figure out how we want to show users this information and implement it. I view this as a high priority based on feedback from folks on the Growth and Abstract Wikipedia teams, who have noted that it is currently difficult to access this information.
• Isolate styles in the demo pane T296106: The docs site comes with default VitePress styles, which we do not want polluting the demo page: components should be demonstrated in a clean environment without other styles interfering.
• Add groups to Codex docs sidebar T309109: This was identified during the component architecture discussion that Sarai and I held as a way to facilitate findability and organization of components. A particular issue that this would resolve is T304463, which aims to clarify the distinction between the Lookup and TypeaheadSearch components. T309109 is currently blocked by T308488: VitePress has released a 1.0 version, which includes many changes related to the sidebar, and unfortunately has been a difficult upgrade (I'm currently in the middle of it)

There are also larger questions about displaying different themes on the docs site, e.g. a Vector theme that sets the font size to 14px, which would vastly aid in both code/design review and usage of the docs site by MediaWiki developers. However, I think this is likely blocked by T296689, which is a bear of a task.

There's a loose epic for docs site improvements (T304062) that's more closely related to design; perhaps we should create an epic for docs site infrastructure improvements?

@AnneT I wonder if T313905 would be the proper parent task for some of the tasks you listed?

In T314082#8113331, @egardner wrote:

• Finalize Vue 3 Migration T289017: finalize migration to Vue 3 (by removing the compat build). Continuing to ship the Vue compatibility build in production has negative performance impacts, so moving all existing Vue projects off of it will deliver a benefit to users. This task may take a while and a lot of the work will need to be done by other teams (WMDE, Structured Data, etc), but DST should probably support and assist in this process.

This may also require porting (parts of) MediaSearch to Codex, because MediaSearch's Tabs component may not work well in non-compatibility build of Vue 3. (However, when I did that proof of concept for SSR in MediaSearch, its Tabs component was rendered just fine by the SSR service using non-compat Vue 3, so maybe this won't be an issue).

• Migration of remaining WVUI projects to Codex: Not sure if there is a definitive task for this, but DST can help support the final deprecation of WVUI. This might be a sub-task of the "Finalize Vue 3 Migration" item above.

This is T310243.

• Improvements to linter tools for Vue, ES6, etc: Not sure if there is a task for this either, but current eslint-config-wikimedia ruleset for Vue 3, ES6, etc may need to be updated. This helps ensure teams can follow best practices in front-end development without direct involvement of DST

Most of this work either already has been done, or is ongoing maintenance work as upstream (eslint-plugin-vue) releases new rules that we have to decide whether/how to apply. But there is some work that to do in making sure that repos that use Vue are upgraded to the latest versions of these packages. Automatic updates have broken because manual intervention is required in some cases, so I think we should manually update repos that use Vue. I've filed T314206 for this.

In T314082#8113536, @AnneT wrote:

There are also larger questions about displaying different themes on the docs site, e.g. a Vector theme that sets the font size to 14px, which would vastly aid in both code/design review and usage of the docs site by MediaWiki developers. However, I think this is likely blocked by T296689, which is a bear of a task.

If it's just the font size, maybe this would be easier to deal with? The CSS we currently generate already assumes a base font size of 14px, and all components currently look wrong (too big) on the docs site because it uses a base font size of 16px. Maybe we should just change the base font size on the docs site to 14px for now? Or apply a font-size of 14px in the component demo boxes?

There's also T313767: Set up infrastructure for work-in-progress (WIP) components, does that fit here, or should we consider it part of its parent epic (T311244: Lower the burden of contributing code to Codex) and put that under a different roadmap item? It's an infrastructural change but it's in support of lowering the threshold to contribution.

Another suggestion: T308496: Consider using library-upgrader to manage Vue-related dev dependencies would help keep testing infrastructure consistent across repositories

In T314082#8116969, @Catrope wrote:

In T314082#8113536, @AnneT wrote:

There are also larger questions about displaying different themes on the docs site, e.g. a Vector theme that sets the font size to 14px, which would vastly aid in both code/design review and usage of the docs site by MediaWiki developers. However, I think this is likely blocked by T296689, which is a bear of a task.

If it's just the font size, maybe this would be easier to deal with? The CSS we currently generate already assumes a base font size of 14px, and all components currently look wrong (too big) on the docs site because it uses a base font size of 16px. Maybe we should just change the base font size on the docs site to 14px for now? Or apply a font-size of 14px in the component demo boxes?

Just to be precise, it's not entirely wrong, it's mobile-first, which we've identified together as focus of Codex in the past. The “wrong” is only rightful at this point in time where we just use Vector as consumer of Codex.
Also parts of Vector (article content) will be updated to 16px base as one of the goals of DI's visual refinement's undergoing work. Where our “wrong” font-size will be right in projects like Related Articles.

In T314082#8120291, @Volker_E wrote:

Just to be precise, it's not entirely wrong, it's mobile-first, which we've identified together as focus of Codex in the past. The “wrong” is only rightful at this point in time where we just use Vector as consumer of Codex.
Also parts of Vector (article content) will be updated to 16px base as one of the goals of DI's visual refinement's undergoing work. Where our “wrong” font-size will be right in projects like Related Articles.

Sure, but practically speaking, right now, if you look at calculations in Codex where px values are converted to em values, you'll see that code consistently divide by 14, not 16. So right now all our code assumes a base font size of 14px, and our demos should match that.

(Once Codex is used in other skins and once Vector updates the font size in some places, we'll have to figure out how to address that, and possibly change the base font size.)

Another task that would make it easier for developers to test their Codex changes in MediaWiki: T314507: Allow MediaWiki developers to use their local version of Codex

Hey @NHillard-WMF , do you think we can close this since we now have the technical roadmap to lean on?