Skip to content

Plugin align with real usage#3

Merged
soulgalore merged 2 commits into
mainfrom
plugin-align-with-real-usage
May 31, 2026
Merged

Plugin align with real usage#3
soulgalore merged 2 commits into
mainfrom
plugin-align-with-real-usage

Conversation

@soulgalore
Copy link
Copy Markdown
Member

No description provided.

  The base class advertised open(), close(), and processMessage(message)
  with no parameters, but sitespeed.io has long called them with positional
  arguments — open(context, options), close(options, errors), and
  processMessage(message, queue) — and every built-in plugin already relies on
  those args. The README likewise omitted the positional constructor contract
  that the plugin loader requires (new MyPlugin(options, context, queue)), the
  concurrency class field the queue handler reads, and the framework-level
  lifecycle messages a plugin typically needs to handle.

  The result was that every new plugin author had to read other plugins to
  figure out the real API. This change aligns the JSDoc and the README with how
  sitespeed.io actually drives plugins, without changing behaviour: defaults
  remain no-ops, the abstract guard stays, and existing subclasses keep working.

  Co-authored-by: Claude Opus 4.7 (1M context) [email protected]
  The base class advertised open(), close(), and processMessage(message)
  with no parameters, but sitespeed.io has long called them with positional
  arguments — open(context, options), close(options, errors), and
  processMessage(message, queue) — and every built-in plugin already relies on
  those args. The README likewise omitted the positional constructor contract
  that the plugin loader requires (new MyPlugin(options, context, queue)), the
  concurrency class field the queue handler reads, and the framework-level
  lifecycle messages a plugin typically needs to handle.

  The result was that every new plugin author had to read other plugins to
  figure out the real API. This change aligns the JSDoc and the README with how
  sitespeed.io actually drives plugins, without changing behaviour: defaults
  remain no-ops, the abstract guard stays, and existing subclasses keep working.

  Co-authored-by: Claude Opus 4.7 (1M context) [email protected]
@soulgalore soulgalore merged commit c0fef3a into main May 31, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant