I think this is good, but I'd recommend updating some links.

Thanks @Dogu for volunteering here. @DTorsani-WMF can do design review for this, and I can do code review. We can plan on working on this next sprint (so starting next Monday). That week is a holiday week for many of us (Thanksgiving in the USA) but we'll all be around at the start of the week anyway. On Monday we'll update this task to ensure that all the necessary info is here (or maybe someone can do that today/tomorrow if everything is ready). Let's use this task as the primary place to coordinate, but we can also set up a quick meeting at some point if it's necessary.

In T379412#10337015, @lwatson wrote:

The new JobCard component uses a CSS grid layout to display the job information. It may be worth exploring using CdxCard and overriding its flex styles. We'd benefit from getting Codex styles like card links.

In T366849#10332366, @AnneT wrote:

We aren't migrating any existing TablePagers to Codex though, only creating a new CodexTablePager to be used by new projects. So we could show the dropdown in the pager UI and just tell people not to show it in the filters, if there are any, since it's already covered.

As far as I am aware, there are no PHPUnit tests for TablePager or IndexPager (both of which are abstract classes, and must be subclassed and customized to be instantiated).

@CCiufo-WMF is correct – I was just going to paste a link to the same page in our docs.

In T378177#10326279, @Lucas_Werkmeister_WMDE wrote:

FTR, this change seems to have caused a regression in Special:NewLexeme :/ we’re investigating in T379595.

Note for future investigation:

@Reedy regarding messages, we're in a bit of a weird situation here – I think in this particular case what we really want is a shared set of messages that can be used both by Codex (the JS version) and by Codex PHP. Right now the Codex messages themselves live in MW (which is probably not ideal) and I'm just manually copying them over when I do a release of Codex PHP. There is a dedicated task over at T379429 to figure out a better solution here (which will probably be a breaking change in Codex itself).

In T379800#10320741, @Reedy wrote:

While https://github.com/zordius/lightncandy isn't necessarily the best, it is the mustache implementation we're already using in MW core...

https://github.com/bobthecow/mustache.php would be bringing in another.

This isn't necessarily a bad thing, if longer term there was a plan to standardise. Otherwise it's just adding to our pile of Technical-Debt

If using CodexExample is not feasible for whatever reason, then I think we could look at converting Special:AllMessages. This page is available on every wiki and would be easy to stage, share patchdemos, etc.

In T379800#10319433, @sbassett wrote:

@egardner - End of Q2 2024? - as in, by the end of December 2024? I don't believe there is any way we can accommodate that date.

My understanding is that SCC ignores files listed in .gitignore by default (which includes vendor and node_modules).

Here is the scc analysis of Codex PHP:

I'm going to set this as blocked pending T379800.

@Jdlrobson we don't have time in our current sprint (this week and next week) but maybe we can look into this (or help with code review) at some point after that.

We might need to add a new table empty state message to MW's Codex i18n files – for the time being I'm just copying those JSON files over into Codex PHP every time I do a release there.

I've filed T379429 on the Codex 2.0 workboard, as a stub task we can come back to at some point in the future.

We will use https://phabricator.wikimedia.org/T379395 to prototype this approach for a basic Container component. If that works well we will write an ADR documenting this (as part of that task).