Inconsistent `range` Values in Error Diagnostics for Different AsyncAPI File Formats

[KhudaDad414]

Describe the Bug

When parsing an invalid AsyncAPI document, the parser consistently returns range values that seem to correspond to a JSON-formatted document, regardless of the actual file format (YAML or JSON). This inconsistency can lead to confusion, as the error locations might not accurately reflect the structure of the file being parsed.

Steps to Reproduce

1. Create two invalid AsyncAPI documents: one in YAML format and the other in JSON format. Ensure that the errors in both documents are structurally similar but occur at different lines or positions due to format differences.
2. Parse both files using the AsyncAPI parser.
3. Compare the diagnostics.range values returned for each file.

Expected Behavior

The parser should accurately reflect the error locations in the diagnostics.range values for both YAML and JSON formats. Since YAML and JSON have different structuring and syntax, errors in similar constructs should appear at different locations in the respective formats. Accurate error reporting is crucial for effective debugging and file validation.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[smoya]

Another use case:

• YAML version: it says the error is in line 237, but that's not true.
• JSON version: The error keeps saying is in line 237, but this time it is true.

[aeworxet]

Both packages @stoplight/yaml and @stoplight/json for figuring out the location in an input document use a file with the exact same name, getLocationForJsonPath.ts, and a function with the exact same name, getLocationForJsonPath(). They are not explicitly imported on each application, so this bug might simply be caused by using getLocationForJsonPath() meant for a JSON when there's a need to use a YAML-specific function. I am checking this variant.

[aeworxet]

This bug is caused by the normalization of YAML to JSON when ensuring the JSON format for the initial input. https://github.com/asyncapi/parser-js/commit/12c42fbe3b1927ae4ad6d73444d43c9fc92f4938

@jonaslagoni, should this normalization be removed or changed somehow?

[aeworxet]

@jonaslagoni responded in Slack

https://asyncapi.slack.com/archives/CQVJXFNQL/p1721987728027619?thread_ts=1721893488.375929&cid=CQVJXFNQL

Removing that code should mean that if the input is yaml (string type) you cant validate it correctly

and the conversation continues there for now.

[aeworxet]

Submitted PR https://github.com/asyncapi/studio/pull/1126, which is step 2 of 2 in fully fixing this bug for Studio