foundry revisit

README.md

A few nights ago, I wrote down some thoughts on the next iteration of foundry. Here are those notes:

https://gist.github.com/twolfson/1eeb9a4610b9311b3126

Today upon reviewing those notes, I started to brainstorm package.json format. Here are our thoughts:

// package.json
{
  // Not so great since there is no key for `options` but lowest order possibility
  "release": [
    "foundry-release-git",
    "foundry-release-npm",
    ...
  ]
}

// package.json
{
  "release": {
    // Need to consider renaming to commands
    "plugins": [
      "foundry-release-git",
      "foundry-release-npm",
      ...
    ]
  }
}

// TODO: How do we handle different orders with "change files/"register"? Maybe we don't for now and will allow per-step command overrides later on?

// package.json
{
  "release": {
    // Need to consider renaming to commands
    "plugins": [
      "foundry-release-git",
      "foundry-release-npm",
      // TODO: This is why we need per-step options because this should only run in "change files"
      {
        "type": "command",
        "command": "./update-changelog.sh"
      }
      ...
    ]
  }
}

This is also a slick way to handle per-plugin configs:

// package.json
{
  "release": {
    // Need to consider renaming to commands
    "plugins": [
      {
        "command": "foundry-release-git",
        "config": {
           "usePrefix": "v" // e.g. v1.0.5 vs 1.0.5
        }
      }
      "foundry-release-npm",
      // TODO: This is why we need per-step options because this should only run in "change files"
      {
        "type": "command",
        "command": "./update-changelog.sh"
      }
      ...
    ]
  }
}

but in reality, if we are executing them via CLI, then that's not so practical...

Maybe use something like this to handle when a command is run:

// package.json
{
  "release": {
    // Need to consider renaming to commands
    "plugins": [
      "foundry-release-git",
      "foundry-release-npm",
      {
        "type": "command",
        "update_files": "./update-changelog.sh"

        // and then with per-config options
        "publish": {
          "command": "./publish.sh",
          "allow_failure": true
        }
      }
      ...
    ]
  }
}

Sooo maybe the format will be:

// package.json
{
  "release": {
    "steps": [
      // Short form for `plugins`
      "foundry-release-git",
      // Long form for `plugins`
      //   a plugin is defined as a command that has `update-files`, `commit`, `register`, and `publish` subcommands
      {
        "type": "plugin",
        "command": "foundry-release-npm"
      },
      // Command format (allows any non-plugin command but requires at least 1 step to be provided)
      {
        "type": "command",
        "update_files": "./update-changelog.sh"
      }
      ...
    ]
  }
}

Aaaand to make the config reusable for foundry itself in the plugin sense, rename that key to foundry and maybe rename steps to release or release_order for the plugins/commands.

We should prob move to camelCase for consistency in package.json

// package.json
{
  "foundry": {
    "release": [
      // Short form for `plugins`
      "foundry-release-git",
      // Long form for `plugins`
      //   a plugin is defined as a command that has `update-files`, `commit`, `register`, and `publish` subcommands
      {
        "type": "plugin",
        "command": "foundry-release-npm"
      },
      // Command format (allows any non-plugin command but requires at least 1 step to be provided)
      {
        "type": "command",
        "update_files": "./update-changelog.sh"
      }
      ...
    ]
  }
}

Here is how we would handle a one-off package.json:

// package.json
{
  "foundry": {
    "release": [
      {
        "type": "command",
        // Or maybe mark `package.json` as private and use it as a plugin. In either case, solved :tada:
        "update-files": "foundry-release-npm update-files --path app/package.json"
      }
    ]
  }
}