Support declarative format for deployment configurations

[siddharthvp]

Wikiploy is a cool tool, but the need to write JavaScript code for deploy configurations seems avoidable. The package can be easier to use if it allows configurations in a declarative format like YAML. The JS API can of course be retained for advanced scenarios with custom edit summaries, etc.

Example wikiploy.yml file to be placed in repo root:

dev:
  site: test.wikipedia.org
  source: src/xyz.js
  destination: User:SD0001/xyz.js

prod:
  site: en.wikipedia.org
  source: src/xyz.js
  destination: User:SD0001/sandbox/xyz.js

The format can be easily expanded to support multiple files per configuration, edit summaries with placeholder substitutions, etc.

Running npx wikiploy dev would deploy using the dev configuration, and so on.

[Eccenux]

Hi, the idea is interesting, but not sure if yml is the way to go.

Personally not a fan of yml, especially when my head is in JS space... But some kind of basic configuration file support should be fairly easy. Personally would prefer JSON-C or plain JS object (probably better if you would want to import something). I guess if there would be some kind of a converter then people could choose either yml, jsonc or js config.

Seems like a lot of work so I would need to know there's more interest in this feature.

Another problem would be if someone starts with a config file but then want to do something more complicated. So a converter from config to JS should probably be added to fill the gap.

[siddharthvp]

Personally not a fan of yml, especially when my head is in JS space... But some kind of basic configuration file support should be fairly easy. Personally would prefer JSON-C or plain JS object (probably better if you would want to import something).

You could recognize all of .wikiployrc, .wikiploy.{json,yaml,yml,js,mjs,cjs,ts,mts,cts}, and a field in package.json (in an order of precedence). Prettier and lint-staged follow this model.

Another problem would be if someone starts with a config file but then want to do something more complicated. So a converter from config to JS should probably be added to fill the gap.

I don't think that's necessary for a first iteration.