feat: console error messages and better names for requests imported from openapi

[sawa-ko]

Closes #

Description

This PR shows an error message in console when an error occurs when parsing the OpenAPi file, since actually there is no error message, just a generic message, and it is impossible to know why the import failed (I spent 30 minutes looking for what was wrong with my file lol).

Also, in the requests, we currently try to obtain the name with the following steps:

1. From its operationId property
2. From its summary property
3. Default generic name

Currently, most of the request names always arrive in this 3rd step because usually the schemas that I have found do not define the summary property or things like that, so in this PR we try to extract the name from the URL of the request, so that the name is more understandable and not have folder with requests named as untitled request. Attached is evidence of how it was before and how it is now.

Before

Now

Checks

• My pull request adheres to the code style of this project
• My code requires changes to the documentation
• I have updated the documentation as required
• All the tests have passed

Additional Information

[JoelJacobStephen]

The changes work as expected. However, there are cases where the url can contain variables (eg. /pet/{petID}, in this case, the name given will be <<petID>> if there are no operationID or summary properties). I am not sure that's a good approach to the naming scheme in this case. @amk-dev Can I get your thoughts on this?

[amk-dev]

here this logic will miss some edge cases,

i belive you're assuming that the tag will always be present in the path, but that won't always be the case.

1. what happens if the tag is no way related to the path ?
2. adding the tag length makes sense only if the tag is found in the path, otherwise you're adding the length to -1, which does not makes much sense.

[sawa-ko]

No. If it does not have a tag then the condition is not met and is saved as a request without a title. What I can do is save it with the name of the controller in the request in case it don't have tags.

[amk-dev]

I quoted the wrong lines actually. the comment is meant for the next line.

const pathStartIndex =
          openAPIPath.indexOf(info.tags[0]) + info.tags[0].length

and i didn't mean when the tag is not present, i meant when a tag is present but it is not in the url.

like this,

/categories/{categoryId}/items:
    get:
      tags:
        - SomethingNonRelatedToTheURL

[sawa-ko]

I've been thinking about it, and I can't find a way to know from which text index to parse the url as name, any idea? My initial motivation for using the tags was because normally people generate the openapi specs automatically based on the code in their apis, but with the point that the first tag may not be the controller itself, I can't think of another idea.

[amk-dev]

when naming the request, here it seems we're considering the first value after the tag only, eg: the current logic will name /categories/<<categoryID>/update as <<categoryID>>, but i would prefer the request to be named, whatever the remaining path is after the tag. in this case <<categoryID>>/update