From @Krinkle
It took me quite a while to figure what file should (not) be modified,
what command to run to generate the other files, then to undo those
changes after realizing it had overwritten the previous versions, etc.I was expecting that jsonschema-tools would find all current.yaml
files, and expand them all (at least any that are new or changed).
But, it seems this is not the case. The materialize command is for
one-offs only, and materialize-modified only works for changing files
that already existed (plus needs -G to suppress a security warning).
For new files, one first needs to stage them with 'git add' and then
run the materialize-modified with -s to expand it.It seems with the current tooling, the quickest way involving the least
steps for new files is to pass the file to jsonschema-tools materialize
(instead of passing it to git-add and then run another command, and
then another git-add).
If I run this [the npm postinstall hook that installs the jsonschema-tools git hook] in fresh-node or one of the various container or VM dev envs we have, the hook will be rejected. If I run partly inside (to install) and then partly outside (for the commit), then the latter will either fail due to npm not being present or will essentially escape the sandbox and run lots of unaudited dev code from npm on the host machine with full disk, ssh, gpg, Git, and web browser access.
Having the script work standalone means that those without prod access or using secondary devices for this can continue to run it bare, and those with, can run "npm install" (once) and "npm run build" from inside their dev env, and then add/commit from their host as normal.