bluehawk from config proposal

bluehawk-config-example.ts

// usage: bluehawk exec path/to/config.[js|ts|json]

interface ConfigAction {
  action: "snip" | "copy" | "check";
  input: string;
  output: string;
  ignore?: string[];
  state?: string;
  format?: "rst" | "md" | "docusaurus";  // or arbitrary string perhaps?
}


type ConfigExport = ConfigAction[];

// ---------------------------
// EXAMPLE:

// example file: myConfig.ts

const configToBluehawk: ConfigExport = [
  {
    action: "snip",
    input: "myfile.js",
    output: "some_dir/",
  },
  {
    action: "copy",
    input: "other_dir",
    output: "some_dir/",
  },
  {
    action: "snip",
    input: "file-with-state.js",
    output: "some_dir/idk/",
    state: "idk",
  },
];

export default configToBluehawk;

// example usage: bluehawk exec myConfig.ts

i think being able to automatically run bluehawk actions based off of a config file is an important next step to fully realizing the promise of bluehawk. for example, if bluehawking is based on config, with a bit of CI automation, you could arguably not even have to commit the generated files, just running bluehawk exec myConfig when you push your code to remote. plus you get a record of everything you're bluehawking (and have ever bluehawked) in one file the git history.

in the WTD presentation on bluehawk, i was going to talk about this as the next step for Bluehawk, but had to cut it due to time constraints. but you can see the slides here - https://docs.google.com/presentation/d/1hK1hj2FCH4eJlG0kK2i4LgEiKFzNMnzWDHfsbTLMZnc/edit#slide=id.g12151ce0621_0_219

I like the interface (how the file would look)!

I think the implementation would want to be more flexible. Specific actions actually have specific arg types that are already defined. You can leverage those in the implementation. This actually means if the action is, say, "git-copy" then the "ConfigAction" object would have the options specifically for git-copy rather than making those options available to all other actions.

Would it only support .ts? What about simple json/yaml? (see confyglot)

I think the configuration file might also want to have info about plugins and other high-level CLI options before the command list.

I think the implementation would want to be more flexible. Specific actions actually have specific arg types that are already defined. You can leverage those in the implementation. This actually means if the action is, say, "git-copy" then the "ConfigAction" object would have the options specifically for git-copy rather than making those options available to all other actions.

i don't fully understand what you're recommending we do here but am broadly supportive of the goals to:

1. make implementation more flexible
2. depend on existing config code

Would it only support .ts? What about simple json/yaml? (see confyglot)

that's cool. i was thinking js/ts/json. but if we can support these other ones for 'free', let's do that as well.

I think the configuration file might also want to have info about plugins and other high-level CLI options before the command list.

make sense to me. what other high level CLI options would there be besides commands and plugins?

per this, the API for the config file could look like:

{
  plugins: ['plugin-1', 'plugin-2', ...otherPlugins] 
  commands: [
    {
      action: "snip",
      input: "myfile.js",
      output: "some_dir/",
    },
    {
      action: "copy",
      input: "other_dir",
      output: "some_dir/",
    },
    {
      action: "snip",
      input: "file-with-state.js",
      output: "some_dir/idk/",
      state: "idk",
    },
  ],
  // any other top level properties we want to include.
  // can also add more down the line as project evolves.
}

That updated looks good to me. Check cli.ts - I think it would be plugin rather than plugins.

The problem I see with supporting .ts is you need to then have transpiler support in the client's workspace. I can see the potential of adding support for pure JS - like we do with plugins - but right now it doesn't even seem like that is that essential since this is basically just a list of CLI commands and options.

We can talk on zoom about the implementation details, I can show you how I think you would go about leveraging the existing types in TypeScript.

sgtm