Quick Summary

If you are using mw.track( 'event.SchemaName', .. ), there is nothing to migrate.

If you are using mw.eventLog.logEvent, then there is no longer any need to load schema.* modules.
You can now directly use mw.loader.using( 'ext.eventLogging' ).then(... use mw.eventLog.logEvent as before ...). You should keep the EventLoggingSchemas section of extension.json, however, that's needed to know which revision of the schema to encapsulate the event with.

EventLogging will no longer validate your events client-side on every page view by default.

To automatically validate events, enable debug mode by setting the eventlogging-display-web user preference, see Debug mode to learn how.

The Detail

With T187207 we changed the EventLogging javascript client. We removed validation of events and stripped out ResourceLoader schema modules. So, before this change you would do:

mw.loader.using( 'schema.Example' ).then( () => {
  mw.eventLog.logEvent( 'Example', { some: 'data', here: true } ) );
} );

(no, they won't let you use arrow functions :(, but it's just docs so I can be fancy). This worked as follows:

• the schema.Example module contained the schema json, which was added to mw.eventLog.schemas (private) with declareSchema (private).
• this module also depended on ext.eventLogging, so using it also provided mw.eventLog.
• the call to mw.eventLog.logEvent validated the event you passed against the schema and sent it, regardless of validation result.

Now, after this change, you have two migration options:

For backwards compatibility, the schema modules still exist. We just emptied them out and kept their dependency on ext.eventLogging with a deprecation warning.

• Switch to using( 'ext.eventLogging' ) before the schema modules are completely removed in the future.
• Switch to the lightweight subscriber method (preferred), via mw.track().