Page MenuHomePhabricator

[Proposal] Create a new "codex-mw" package for shared MediaWiki-specific components
Open, Needs TriagePublic

Description

Background

From its inception, we have intended for Codex to exist as a "MediaWiki-agnostic" library, where components are generic and have zero knowledge of MW APIs. This level of independence is good and we should continue to develop Codex along these lines (it will greatly increase the usefulness of the library in non-MW environments, like Toolforge, dashboards, etc).

However, there are a couple of needs that have come up which are difficult to address in a fully generic component library:

  • We need a place for shared MediaWiki-specific components that build on top of Codex
  • We need a way to perform code splitting to create tailored JS/CSS bundles that only contain the code for a particular feature (for performance reasons)

Proposal

Let's address both of these needs by creating a MediaWiki-specific "superset" of Codex, either as a new workspace within the Codex monorepo or as a stand-alone repository.

Shared MW-aware components

This new codebase could house any shared MW-specific components that we or other WMF teams create. These components could be less generic and more purpose-built than their base-level counterparts in the core Codex workspace. This "codex-mw" software package would still depend on @wikimedia/codex, so all base components would be available here.

Feature-specific Codex builds

In addition to housing shared, MW-aware components, "codex-mw" could also be the place where we define feature-specific builds of the library. In MediaWiki itself, the lack of front-end build tooling (T279108) and a Node.js environment (T328699) prevents us from doing automated code-splitting or tree-shaking. Outside of MW, this is not a problem – Vite (the Codex build tool) has powerful code-splitting features, and we could define an arbitrary number of "endpoints" to build any sub- or super-sets of Codex that teams require.

@Catrope can elaborate on the technical aspects of how we would do this in Vite if necessary. The specific feature is called Library Mode, and as of Vite v3.2, multiple entry points in Library Mode are supported.

Other Considerations
  • This is work that could begin now, if we decide that we want to do it
  • The name does not need to be codex-mw, but that is my default for the time being
  • My assumption is that DST would still "own" this new codebase but we'd want to encourage a higher level of participation by other teams here
  • The inclusion of TypeaheadSearch in Codex has caused a lot of confusion (it doesn't fit well with the "Codex is independent of MediaWiki" rule mentioned above), and that component already needs its own codex-search build of the library due to the performance constraints of the Web team. This component would be a good candidate to move into this new codebase. Perhaps things like the OnboardingDialog (a purpose-specific customization of the generic Dialog component) would also be a good fit here
  • @Jdlrobson was asking about a way to get just the CSS for the Message component to use in ResourceLoader; we could easily define a message-only library endpoint here in order to produce this code
  • In general we could probably support a lot of CSS-only component usage in this way
  • As mentioned above, this new codebase could exist either as an additional workspace inside the existing Codex monorepo, or a new stand-alone repo could be created

Event Timeline

Creating and updating feature-specific builds could be burdensome, both for feature developers and us (I assume DST would maintain codex-mw). I'm curious what it would look like to export each Codex component separately, perhaps along with a bundle of types and a bundle of composables. It would be great if dev users could just include the components they need directly in their feature code rather than needing to maintain something in a separate repo.