Persisting context for multiple projects

[Souvikns]

context should be optional, and I still should be able to pass context with a flag in case I'm doing some automation, or working with multiple files.

context should also be smart in the way that if I do not have context set, and I do not pass --context command, CLI check if there are files called asyncapi.json/yml/yaml in workdir, and picks them up.

context should most probably be persisted in a file.

I think we should store the context as a key:value pair of the directory the command was invoked to the context path

asyncapi context /path/to/spec/file

this command will save the {process.cwd(): "/path/to/spec/file"}, this way we can persist
the context for that specific folder/workspaces.

[Souvikns]

I was thinking about the commands for setting the context and then also overriding it if the user wants. @derberg do let me know what you think about this -

To set, update and delete the context

asyncapi context --set <specPath | URL> set or update the context 
asyncapi context --remove clear the context 

To override the context or to use a temporary context we can have a --spec flag which would be a root level option.

asyncapi --spec=file/path/or/url generate <template>

[derberg]

I very much like kubectl and not having actions as flags, have a look at https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-context-and-configuration

asyncapi config get-contexts                          # display list of files in the context of the CLI
asyncapi config current-context                     # display the name of the file that is currently a context of the CLI
asyncapi config use-context myasyncapi

thoughts?

[Souvikns]

I very much like kubectl and not having actions as flags, have a look at https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-context-and-configuration

asyncapi config get-contexts                          # display list of files in the context of the CLI
asyncapi config current-context                     # display the name of the file that is currently a context of the CLI
asyncapi config use-context myasyncapi

thoughts?

Yeah, this is better, it's clear to understand.

So instead of flags, we use commands like

asyncapi context set <path|URL>
asyncapi context remove

So if context is a command then set and remove is an argument. Still, I guess we should have a flag if the user wants to override the context in any case.

---

One thing I would like to clarify, about saving the context. As we will be saving the <filePath | URL> of the spec file.
Most users will install CLI globally where they might have different projects that are using async API spec file for their development. If we have a single context then the user has to change/update the context every time he switches from one workspace to another. @derberg what do you think, we should do for this scenario.

• One thing we can do is to let users save context in key-value pair where they can switch easily.
• We save the context in a key-value pair from where the context set command was called. then the user doesn't have to update the context every time he opens a new folder.

[derberg]

except for setting and removing, user also needs a way to list all (to know which one to set) and to check what is the current.

the best would be to save the context file as .asyncapi in the "home" of the user, so where all files like .npm, .docker, .bash_profile and others. It is the best place because long term we need to make sure npm is not needed to install the CLI and should check out possibilities to publish it on managers like brew

[Souvikns]

@derberg to sum up, how about these commands for the context.

asyncapi context set <context-name> <filePath | URL>   | set context 
asyncapi context current                               | get the current set context 
asyncapi context list                                  | list all the contexts 
asyncapi context remove                                | remove the current set context

[derberg]

if I want to switch from context A to B, would I use set? or we probably need use, right? this is how I have it in nvm, I do nvm use <node version> after listing what I have

[Souvikns]

Yeah, use makes much more sense, but if use is changing the set context should we have another command for creating a new context value to be saved in the .asyncapi file, or use command will update/create a new context accordingly

[derberg]

use will be only for using existing one, set will be for setting a new one (and automatically set as current). Makes sense?

[Souvikns]

use will be only for using existing one, set` will be for setting a new one (and automatically set as current). Makes sense?

ok, got it. 👍🏻

[Souvikns]

@derberg shall I start working on this issue 😊.

[derberg]

@Souvikns I think it is about time. Just consider as small PRs as possible to make review and merge process easy, so not all commands at start.

also current --context flag will need to be fixed as now it points to a file and not context name, we just need another --file flag

[asyncapi-bot]

🎉 This issue has been resolved in version 0.2.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀