Support plugin mechanism

[jianzs]

Objective

To meet requirements such as cost control and global network configurations, there is a need for a method to modify the generated IaC code. These types of requirements are best represented as rules and implemented as plugins.

Usage: Plugin Configuration

Plugins are scoped to a stack. Within a stack, the plugins field can be added to configure multiple plugins in a list. For instance, setting up a custom domain or VPC configuration might look like this:

stacks:
- name: dev
  # other configurations...
  plugins:
  - package: add-custom-domain
    configs:
      domain: foo
      type: foo
  - package: add-vpc
    configs:
      cidr: 10.0.0.0/16

Each plugin contains two parts: package and configs. The package specifies the plugin's package name or can directly point to a file. configs are the plugin's related configurations, which are passed to the plugin's constructor during its construction.

The plugin can be an npm package or a JavaScript file. There is also the possibility of supporting plugins written in multiple languages, for example, using the mutation capabilities of KCL.

Implementation

To address the need to modify IaC code, after generating the IaC code, actively invoke each plugin in sequence, maintaining the input and output format consistent with the output of the generator.

In the future, there might be more configurability requirements within the entire Pluto workflow. It would be possible to set multiple events throughout the lifecycle of the workflow, such as before:deduce, after:generate, etc. Plugins would register hooks for the events they are interested in, and Pluto would trigger the corresponding hooks.