Relative references not working correctly.

[alexkaufman06]

I'm seeing the issue mentioned here with "@apidevtools/json-schema-ref-parser": "^11.5.4",: https://github.com/APIDevTools/json-schema-ref-parser/issues/251

[jonluca]

Can you share an example?

[alexkaufman06]

Can you share an example?

Here is an example repo: https://github.com/alexkaufman06/example-issue If you clone it and run npm i followed by npm run dref:json you should see an error opening file and no such directory.

If I change the refs from ../common/components to ./common/components it works but I don't think I should have to.

[alexkaufman06]

@jonluca let me know if you need anymore info. Looks like this PR attempted to fix it but didn't have tests: https://github.com/APIDevTools/json-schema-ref-parser/pull/261/files

[denver-HJS]

I have this same issue in my repository. @jonluca would it make sense to resurrect #261?

[jonluca]

@alexkaufman06 the issue with your example is that you are loading the yaml into an object in memory. This loses the information about where the file is on disk, so we have to fall back to making the relative references relative to the current working directory.

When you do

const fileContents = fs.readFileSync(`./api/${file}`, 'utf8');
const mySchema = yaml.load(fileContents);

The contents of mySchema does not contain its original location on disk - it does not know that it is in the api directory, so we now it falls back to thinking that we're in os.cwd(), which is the root folder.

I dont believe this is an issue with the library. Theres no way for us to know where the file is once you pass in an object and not a file path. If you change your code to pass in the file path instead, it works properly:

let clonedSchema = await $RefParser.dereference(./api/${file}, { mutateInputSchema: false });

[jonluca]

I have this same issue in my repository. @jonluca would it make sense to resurrect #261?

Does #261 solve a different issue? Could you include a separate relative referencing parsing error example?

[denver-HJS]

I have this same issue in my repository. @jonluca would it make sense to resurrect #261?

Does #261 solve a different issue? Could you include a separate relative referencing parsing error example?

Actually I was using the same approach as @alexkaufman06, so your suggestion addresses both of our issues/questions. Thank you for pointing us to the fix! 🙇

[alexkaufman06]

Thanks for the fix @jonluca! 😅 🙇