feat: add plugin clients

[dylankilkenny]

Summary

Plugin Client Architecture:

• Three-tier inheritance pattern (BasePluginClient → Base{Service}Client → Direct/Relayer clients)
• Hierarchical error system (PluginTransportError, PluginExecutionError, PluginUnexpectedError)
• Strategy pattern for transport abstraction (direct HTTP vs relayer)
• Automatic payload wrapping, response parsing, and metadata handling

Launchtube Client:

• LaunchtubeClient - Direct HTTP connection to Launchtube service
• LaunchtubeRelayerClient - Connection via OpenZeppelin Relayer plugin
• Supports transaction submission (XDR or func+auth) and sequence account management

Channels Client:

• ChannelsClient - Direct HTTP connection to Channels service
• ChannelsRelayerClient - Connection via OpenZeppelin Relayer plugin
• Supports parallel transaction submission and channel account management

Documentation & Examples:

• Developer guide in plugin-clients/README.md with architecture and patterns
• Example scripts for both direct and relayer modes
• Updated post-generate script to copy plugin clients from plugin-clients/ to src/clients/

Testing Process

Checklist

• Add a reference to related issues in the PR description.
• Add unit tests if applicable.
• Add the changeset file. (run npx changeset add)

[Copilot]

Pull Request Overview

This PR adds plugin client functionality to the OpenZeppelin Relayer SDK, introducing a modular architecture for interacting with plugin services both directly via HTTP and through the OpenZeppelin Relayer. The implementation includes clients for Launchtube and Channels services, along with a comprehensive error handling system.

Key changes:

• Introduces a three-tier inheritance hierarchy for plugin clients (BasePluginClient → Service-specific base → Concrete implementations)
• Adds Launchtube and Channels client implementations with both direct HTTP and relayer modes
• Updates build scripts to copy plugin client code from plugin-clients/ to src/clients/ during generation
• Improves code formatting and ESLint comment consistency across model files

Reviewed Changes

Copilot reviewed 39 out of 40 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/clients/base/base-plugin-client.ts	Core abstract base class providing payload wrapping, response parsing, and error handling
src/clients/base/errors.ts	Error hierarchy for plugin operations (transport, execution, client errors)
src/clients/launchtube/*.ts	Launchtube client implementations for direct HTTP and relayer modes
src/clients/channels/*.ts	Channels client implementations for direct HTTP and relayer modes
scripts/post-generate.js	Build script updated to copy plugin-clients to src/clients with path normalization
src/models/solana-rpc-result.ts	Formatting improvements and better ESLint comments
src/models/plugin-api.ts	ESLint comment formatting standardized
examples/clients/*.ts	Example files demonstrating client usage

Files not reviewed (1)

• examples/relayers/stellar/pnpm-lock.yaml: Language not supported

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The eslint-disable-next-line comment is placed after the code it's supposed to suppress, making it ineffective. It should be placed on the line before the violation. Move the comment to line 29 (before the variable declaration).

Suggested change

	let responseBody: any; // eslint-disable-next-line @typescript-eslint/no-explicit-any
	// eslint-disable-next-line @typescript-eslint/no-explicit-any
	let responseBody: any;

[Copilot]

The eslint-disable-next-line comment is placed after the code it's supposed to suppress, making it ineffective. It should be placed on the line before the violation. Move the comment to line 29 (before the variable declaration).

Suggested change

	let responseBody: any; // eslint-disable-next-line @typescript-eslint/no-explicit-any
	// eslint-disable-next-line @typescript-eslint/no-explicit-any
	let responseBody: any;

[zeljkoX]

Thanks for working on this!

I need to better understand decisions behind this PR.

At first sight in my opinion this approach is not scalable.

In the future there would be more plugins, added by internal or external contributors and we should not have clients for every plugin here.

In addition to that not every user would use plugins so that means unnecessary code.

Plugins are now simple, just one execution endpoint that is covered by exported plugins api.

I wonder why simple wrapper around sdk is not good enough, potentially at plugin repo?

Every plugin client is just logic how to structure endpoint request data.