feat!: vervet generate command #152
Conversation
cmars
force-pushed
the
feat/generate-cmd
branch
2 times, most recently
from
93570ec
to
a9e1c25
Compare
cmars
force-pushed
the
feat/generate-cmd
branch
2 times, most recently
from
3578b32
to
7a28af0
Compare
| ArgsUsage: "[api [resource]]", | ||
| Action: VersionList, | ||
| }, { | ||
| Name: "new", |
There was a problem hiding this comment.
Was dropping new support intentional?
There was a problem hiding this comment.
Yes. vervet generate is intended to replace it. vervet version new operated in the context of a "Vervet project" owning the generators and applying them unconditionally to all resource versions. vervet generate breaks this functionality up so that you can generate from templates defined outside of the project.
This makes the generation capability more open and extensible for use outside of the context of a particular project -- templates can then be bundled and applied to any project. https://github.com/snyk/rest-node-generate will be one of these, planned rest-go-generate is another.
Also want to kill the vervet version command. Lots of feedback from the last workshop that it was confusing (it doesn't tell me the version of vervet?).
cmars
force-pushed
the
feat/generate-cmd
branch
3 times, most recently
from
8305473
to
c4a3287
Compare
Instead of chaining vervet's templating capabilities on to OpenAPI version aggregation and compilation, this breaks generators out to a separate command a la `go generate`. Generators are more focused on code generation driven by trees of OpenAPI, which "own" the generated files. Prior experimental functionality around OpenAPI bootstrapping and scaffolds are also removed. We want `optic run` scripting to manage OpenAPI, and template projects instead of project generators. Drive-bys: - Remove `vervet scaffold` command. Prefer template projects. - Rename `vervet version` to `vervet resource` -- confusing subcommand. Sub-sub-commands also renamed to align with drifted purpose. - Rename `vervet compile` to `vervet build`.
Move cmd -> internal/cmd to avoid making the command internals part of the public API surface. Remove the old sweater-comb linter, which used to be a Docker-packaged Spectral linter. 'sweater-comb' is now an alias for optic-ci.
Instead of chaining vervet's templating capabilities on to OpenAPI
version aggregation and compilation, this breaks generators out to a
separate command a la
go generate. Generators are more focused on codegeneration driven by trees of OpenAPI, which "own" the generated files.
Prior experimental functionality around OpenAPI bootstrapping and
scaffolds are also removed. We want
optic runscripting to manageOpenAPI, and template projects instead of project generators.