Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce an "init" subcommand for bootstrapping a package #448

Open
czechboy0 opened this issue Dec 8, 2023 · 3 comments
Open

Introduce an "init" subcommand for bootstrapping a package #448

czechboy0 opened this issue Dec 8, 2023 · 3 comments
Labels
area/generator Affects: plugin, CLI, config file. kind/usability Usability of generated code, ergonomics. status/needs-design Needs further discussion and a concrete proposal.
Milestone

Comments

@czechboy0
Copy link
Collaborator

czechboy0 commented Dec 8, 2023

Introduce an "init" subcommand for bootstrapping a package.

At the very least, should bootstrap (decision: client vs server, asked by the CLI):

  • Package.swift
  • a new Hello World-like OpenAPI document (or an existing one can be provided by the user in the command)
  • main.swift/Tool.swift with the entry point and basic code to get things working with swift run
  • config file with reasonable defaults

For example: swift-openapi-generator init-package --mode client would create a new package, with a simple OpenAPI doc, and the generator configured etc. This package would work out of the box with swift run. Just need two variants: client and server.

@czechboy0 czechboy0 added area/generator Affects: plugin, CLI, config file. status/needs-design Needs further discussion and a concrete proposal. kind/usability Usability of generated code, ergonomics. labels Dec 8, 2023
@czechboy0 czechboy0 added this to the Post-1.0 milestone Dec 8, 2023
@simonjbeaumont
Copy link
Collaborator

Just need two variants: client and server.

No types?

@czechboy0 czechboy0 changed the title Introduce an "init-package" subcommand for bootstrapping a package Introduce an "init" subcommand for bootstrapping a package Dec 8, 2023
@czechboy0
Copy link
Collaborator Author

I think splitting types is a more advanced use case where we don't know what to generate for the executable (would there even be an executable?). Client and server are easy, basically our Hello World examples, just with a customizable name etc. But Types might need more thought. But ofc we can include it if we identify a common enough pattern to make it worth it.

@simonjbeaumont
Copy link
Collaborator

I was thinking it would generate a library target, without an executable.

Which begs the question: what should we generate for client? I assumed we would generate a library target with package access modifier and an executable, but potentially you thought just an executable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/generator Affects: plugin, CLI, config file. kind/usability Usability of generated code, ergonomics. status/needs-design Needs further discussion and a concrete proposal.
Projects
None yet
Development

No branches or pull requests

2 participants