WIP: Revamp the cli, sdk - #1
Conversation
There was a problem hiding this comment.
Heh, this is a bit of a... simplistic mixin system. I spent a little while faffing about with the types and trying to get something more elegant, but this isn't exactly the part of the project I wanted to spent a lot of time on so this works for now.
| @@ -0,0 +1,93 @@ | |||
| import * as Types from '../schema'; | |||
There was a problem hiding this comment.
All these .generated.ts files are generated automatically by graphql-codegen.
| `); | ||
|
|
||
| export const getIssue = async (client: Linear, selection: IssueSelection) => { | ||
| if ("id" in selection) { |
There was a problem hiding this comment.
This is an example of a selection in practice. An issue can be selected by id or key. This infrastructure wouldn't be necessary if and issue was queryable by both of these fields.
Granted, GraphQL doesn't support input unions so there's no way in the schema to express that either id or key is required. So very unfortunate...
There was a problem hiding this comment.
I think we could expand the API to support queries where one passes the key ID (XXX-123) as id, and same for teams as well. Then creating issues via the API would be much more simple
jorilallo
left a comment
jorilallo
left a comment
There was a problem hiding this comment.
This looks great. SDK approach makes sense, I think most use cases are simple and there's always the client as fallback. I think @artman might have more comments on the SDK side but for the CLI @oclif looks nice.
As you pointed out, issue creation is tricky. Happy to iterate on it once initial version is out but I would like to keep it light; it should be really fast to create an issue, just title and description and maybe fill the rest after the fact even. I would also like to bring back default team from the previous implementation so it's not required input. If the compose uses $EDITOR, then we could even have some fields in markdown that we could parse for metadata (estimates, labels etc). I have some ideas but excited to get something out to start building on :)
artman
left a comment
artman
left a comment
There was a problem hiding this comment.
Pretty great! Happy to land this as is (I can work through my comments after land), as I think this is a good basis to build upon.
|
Lets land after @artman's comment are addressed |
|
I'll wrap this up on Saturday! 👍 |
d31f55f to
93f2f58
Compare
3 participants
Note: The commit history for these changes got messed up due to an unfortunate rebase when trying to merge my changes into the new repo. Sorry about the lack of context there.
This is pretty highly work in progress.
Getting started
To play around with this, you'll want to put both packages in watch mode.
In one terminal
In another terminal
Finally, from the root of the project run
yarn clito execute the cli.SDK
The sdk exposes a thin graphql request wrapper for interacting with the api. It also exposes base primitives for interacting with things like issues, teams, etc. There's definitely more to be done here.
One concept I'm playing with is the idea of a selection. When you're querying for a project/team/issue/etc there are generally different field that could result in the object you're searching for. For example, an issue will commonly be searched for by a key. I'll expand on this idea later in the PR.
CLI
This is very bare bones at the moment and was just a mechanism to drive useful changes in the SDK. I'm happy with the base architecture of the CLI itself, but I'm not so sold on how the
createcommand currently functions.One of the things that makes Linear stand apart is its user experience. I think the CLI should truly be an extension of that. Guided text interfaces could make it trivial to do things like change issue states or assign labels. Granted, a non-interactive mode is important to provide for automation too. More to come.