The mediawiki.page.watch.ajax bundle is small and loads on all page views. It is mainly responsible for initiating the watch process from the watchstar on click. Anything later is lazy-loaded for performance reasons, with the latency masked/hidden by the API request that happens at the same time.

The mediawiki.watchstar.widgets bundle requires the OOUI framework and is used to render the notification bar for changing the expiry after adding something to your watchlist. The OOUI framework and any other dependencies for this indeed should not be eagerly loaded on all page views.

The idea of loading a JS class that would crash if referenced too early seems fragile and would be a new pattern that we don't currently use anywhere in production. It's worth considering of course, but it's also important to look around if there are other ways to achieve it so as to avoid having to understand and maintain many ways to do the same thing.

A possible alternate reduction in the same general area might be:

• Bundle mediawiki.page.watch.ajax with other small UI code that applies to most page views by most logged-in users. I don't see anything off-hand though, it might be that this is the only thing like it. We have already created bundles for stuff that applies to all users ("mediawiki.page.ready") and stuff that applies to non-default abilities (misc "curate", misc "pref").
• Bundle some of the mediawiki.widgets.* solo class bundles based on common purpose or usage pattern.

Moving to Needs Discussion to determine if the Growth team should make these performance improvements to Watchlist

I suppose mediawiki.page.watch.ajax could lazy-load OOUI and then lazy-declare WatchlistExpiryWidget. Don't know if it's worth the effort.

Per discussion, the Growth team can't work on this in the near term.

The Community Tech team is open to review this task, it's a minor task