feat: created specificationUrl class

[Souvikns]

Description
This PR aims to add support to fetch specification file from url.

• Ultimately the cli will be able to take url as a parameter to resovle commands
• Save url in context
• Fetch specification file from url.

Related issue(s)

Resolves #7

[Souvikns]

load function is returning SpecificationFile instance but to add support for URL paths it feels weird to have fetch function in the SpecificationFile. We could create another SpecificationUrl class that will fetch the data, but I think we should change SpecificationFile to Specification and have two separate functions loadFromFile and loadFromUrl to load the spec file accordingly.

So our load function would look something like this

const spec = await load(filePath);
await parser.parser(spec.text());

need your opinion on this @fmvilas

[fmvilas]

In general, my advice is that we should be reducing the cognitive load of the code, and I think creating more classes and more modules that depend on each other only makes it harder to understand. Remember what we talked about the "hops" you have to do when reading a code. If the only logic that's really different is validating a URL and fetching from a URL, then probably all you need are just "helpers" or external modules that already do that.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[Souvikns]

@fmvilas should startStudio function take file path as input or spec as input. To create URL support I was thinking of making it in a way that every command which needs to read specification from somewhere can just use the load function but it will not get file path or URL or context but rather the specification string or json itself. Studio needs filepath and port to start so it does not support URL as of now.

Also Should studio load specification from URL as it won't be able to update it anyway.

[fmvilas]

Yeah, I don't think Studio needs to be able to open a URL, at least for now. As you said, you'll not be able to edit it anyway so what's the point 🤷‍♂️

[derberg]

I see that @fmvilas already reviews, so from my point of view I only suggest to log a followup issue, something good for the first contribution, to make sure tests do not rely on external resources. Basically, external resources are risky to use in tests and can cause tests to be flaky, like randomly failing just because the external resource is not available. So follow up should describe that tests should actually start independent server hosting asyncapi file, like we do in parser -> https://github.com/asyncapi/parser-js/blob/master/package.json#L20

[derberg]

From my point of view important is that help message spec path or context-name is updated

[fmvilas]

I think you shouldn't call this "URL path". That's a URL.

I mean, this is a URL: https://www.asynapi.com/blog.
And this is the URL path: /blog.

They're not the same and I think here you mean the full URL, not just the path part.

Why not getFileURL()?

Suggested change

	getURLPath() {
	getFileURL() {

If you change it, you'd have to change everything else following similar notation, like const TYPE_URL_PATH = 'url-path';

[derberg]

All good from my side but wait for @fmvilas as he made some good quality review

also you have some merge conflicts in package.json

[derberg]

@fmvilas as you initially requested changes you need to approve before we can merge

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[magicmatatjahu]

Looking at the changes, it's ok for me. You just have to wait for the Fran :)

[fmvilas]

Sorry for the delay. Looks good to me 🚀

[asyncapi-bot]

🎉 This PR is included in version 0.12.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀