Allow for extensions on the context (global, host, workspace, parsers) through config file

Add the ability to extend GenAIScript's core contexts (global, host, workspace, parsers) through a plugin system, enabling users to add custom functionality without modifying core code.

Motivation

Currently, extending GenAIScript requires modifying core files or creating wrapper implementations. Users should be able to:

Add custom workspace file parsers (e.g., .proto, .graphql, custom formats)
Extend the global context with project-specific utilities
Register custom host capabilities (e.g., database connections, API clients)
Add domain-specific tools and helpers

Proposed Solution

Allow plugins to be registered via configuration file:

{
  "plugins": ["./plugins/my-plugin.js", "genaiscript-plugin-database"]
}

Plugin API:

import { plugin } from "genaiscript/plugin"

export default plugin({
  name: 'my-plugin',
  setup(extend, options) {
    extend(({ global, host, workspace, parsers }) => {
      // Extend global context
      global.defTask = (name, fn) => { /* ... */ }
      
      // Add custom parsers
      parsers.readProto = async (file) => { /* ... */ }
      
      // Extend workspace
      workspace.queryDatabase = async (sql) => { /* ... */ }
      
      // Add host capabilities  
      host.customService = () => { /* ... */ }
    })
  }
})

Benefits

Modularity: Keep custom code separate from core framework
Reusability: Share plugins across projects or publish to npm
Type Safety: Plugins can provide TypeScript definitions
Declarative: Clear plugin API with standardized structure
Composable: Multiple plugins can coexist

Thoughts

Should plugins support async initialization?
How to handle plugin conflicts/priorities when multiple plugins extend the same context?
Should plugins have access to all framework internals or sandboxed APIs only?
Should there be lifecycle hooks (beforeRun, afterRun, etc.)?

This is a well-structured proposal with clear motivation and benefits. The need for plugin-based extensibility for GenAIScript is compelling, as it enables modularity, reusability, and adaptability to domain-specific requirements.

A few points to clarify:

Can you describe how the framework will handle conflicts if multiple plugins attempt to extend or overwrite the same context property (e.g., parsers.readProto)? Will there be a priority system or warnings?
Does the plugin API allow for async setup/init, and how would this impact the overall startup sequence? Are there scenarios where plugin initialization order should be controlled?
Would plugins have access only to exposed extension APIs, or is exposing more of the internal framework for advanced plugin authors under consideration?
Lifecycle hooks (e.g., beforeRun/afterRun): Should plugins be able to register for specific framework lifecycle phases, and are there plans for a standardized hook API?
Are there security/sandboxing considerations for loading third-party plugins, especially if plugins can operate at the host or global level?

Overall, the issue provides a strong foundation for a plugin system discussion; addressing the above points could clarify integration, safety, and extensibility.

AI-generated content by issue-reviewer may be incorrect. Use reactions to eval.

There should be warnings. There should be a priority system based on the plugins order.
It should allow async setup.
For starters no need for internal apis
No need for before and after run for now
There are no security considerations since this a developer's responsibilty

Navigation Menu

Repository navigation

Allow for extensions on the context (global, host, workspace, parsers) through config file #1954

Motivation

Proposed Solution

Benefits

Thoughts

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow for extensions on the context (global, host, workspace, parsers) through config file #1954

Description

Motivation

Proposed Solution

Benefits

Thoughts

Activity

github-actions commented on Oct 31, 2025

vkefallinos commented on Nov 1, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions