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"
}
]
}
}