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

[vkefallinos]

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

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

[github-actions]

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.

[vkefallinos]

• 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