Mohamed Boudra
929d2b717e
The daemon imports the plugin SDK at runtime, but the workspace was named @paseo/plugin and marked private, so it was never published. 0.5.0-beta.1 shipped @getpaseo/server depending on a package that does not exist and `npm install @getpaseo/cli@beta` failed with a 404 for every user. Two things hid it. sync-workspace-versions only rewrites deps matching @getpaseo/*, so the "*" range on @paseo/plugin survived untouched into the published tarball. And `npm pack --dry-run`, which is all release:check and CI run, lists files without ever resolving the dependency graph. Renaming to @getpaseo/plugin rather than publishing the old name: @paseo is not our scope on npm, so that name could never have been published at all. The rename also brings the package under the version-sync filter, which is what pins it correctly from here on. Plugins scaffolded against the old name still import @paseo/plugin. Both spellings resolve through plugin-sdk-specifiers.ts, tagged COMPAT with a removal date, so existing plugins keep loading. This does not repair 0.5.0-beta.1 — a published tarball's dependencies cannot be changed. The package publishes with the next release.
Linear plugin example
This example adds Attach Linear issue to the composer. Search by issue identifier
or title, then send a stable issue snapshot to the agent.
Set a personal API key in the daemon environment:
export LINEAR_API_KEY="lin_api_..."
Register the extension in $PASEO_HOME/config.json:
{
"pluginsEnabled": true,
"plugins": {
"linear": {
"source": "directory",
"path": "/absolute/path/to/paseo/plugin-examples/linear"
}
}
}
Restart the development daemon after changing its environment or plugin configuration.
The split entry point demonstrates the complete attachment-source pattern:
- define the validated search RPC and attachment metadata in
issues.shared.ts; - handle it in the daemon subprocess from
issues.server.ts; - wire both contributions from
index.ts; - keep credentials and vendor API calls out of the client bundle.