should `start studio` try and find a local file? about cli

[Souvikns]

Yeah, cli first tries to load context from the global context store and if it fails it checks in the file system for a file naming asyncapi.yml, asyncapi.yaml or asyncapi.json.

Use context anyway (think its checking for defaults not sure?)

@boyney123 here the CLI persists some files paths in the context which is just a .asyncapi file in the homedir. If file path is not present then cli checks this to determine the file path and if this file is missing or not yet created then it looks in the working directory.

So if you have no context created and you have an asyncapi.yml file in your working directory then cli should pick up the asyncapi.yml file.

Will check this 👍🏻

[boyney123]

Any thoughts on this @jonaslagoni @Souvikns?

Or maybe I'm not understanding how context works

[jonaslagoni]

Good question, I see pros and cons for both tbh.

I guess the question falls back to, what is the best user experience when you need to perform actions with specific (or multiple) AsyncAPI documents.

I could see it as being a mix tbh. Where if you want to use context use that, or if you want to specifically provide an input to a specific command, you should be able to do that.

Regarding this issue, I would not assume the CLI to automatically look for a local file, as it is quite error-prone, cause I think it would rarely be called asyncapi.yml, so going through all files would be, too much IMO 😄

[derberg]

asyncapi start studio should be consistent with the rest of the CLI. There was and I hope still is 😄 a fallback mechanism for loading AsyncAPI file, it basically looks for context, default file asyncapi.yml in the context of where command is run, etc!

so yes, we should do automatic for the use, same as in other commands, but also allow to pass --file or --context flags to overwrite defaults. And yes, we should not force user to learn about context concept but throw a full help message that explains what different options user can pick, now I see ContextError: No context is set as current, please set a current context. but I'm 100% sure there was a better error displayed with full help text, but don't see it anymore 😢

[boyney123]

Ahh yeah I just was reading around and found that is already does fall back to files (well tries too).

https://github.com/asyncapi/cli/blob/master/src/models/SpecificationFile.ts#L43

Looks like this line is happening before https://github.com/asyncapi/cli/blob/master/src/models/SpecificationFile.ts#L50

When nothing it passed it will go to load context and just fail if nothing is there, I think this fix is moving those two around.

So flow:

• Use file/context if provided
• Check for local file

I think the current flow is :

• Use file or context name if provided
• Use context anyway (think its checking for defaults not sure?)
• Fall back to file system

But the bug is that set 2 throws the error and never falls back to reading the file system.

[Souvikns]

Yeah, I checked, and even if you don't have the .asyncapi file in your homedir it is not looking into the working directory but failing instead.

And this is happening because of this

cli/src/models/SpecificationFile.ts

Lines 42 to 48 in a5311ff

	try {
	return await loadFromContext();
	} catch (e) {
	if (!filePathOrContextName) {
	throw e;
	}
	}

specifically in line

cli/src/models/SpecificationFile.ts

Line 45 in a5311ff

if (!filePathOrContextName) {

when when no input is passed and it does not find the current context it fails and does not look in the working directory.

[boyney123]

Thanks for looking @Souvikns

when when no input is passed and it does not find the current context it fails and does not look in the working directory.

Yeah I think the fix would be just moving the two parts around, I can raise a PR for this to see what you think

[boyney123]

Made a fix here : #130

[Souvikns]

I think we can close this issue now right?

[boyney123]

Yeah thanks @Souvikns