-
Notifications
You must be signed in to change notification settings - Fork 53
Access schema include paths #140
Comments
Hi @justjacksonn I am not sure what this issue is about, can you clarify? |
Hi @dmartinezg! I asked him to log the issue and it was about being able to get the original Edit: Maybe we can look at a higher level mode for exposing the refs in a transparent object instance that will still JSON stringify to the same structure? It'd also be useful for getting the local reference which are lost (e.g. |
+1 |
Side note: I think the best way to keep backwards compatibility with the current parser would be to have the parser expand JSON schemas inline. It wouldn't require much of a change to support either. Edit: In fact, first result for "json expander" is https://github.com/br-adam-newman/raml-jsonschema-expander. |
Thanks for the links, I think I'll just override By the way, with this kind of preprocessing the underlying issue is still there, now you're not only hiding I'd be okay if there was some new |
@mbixby I definitely understand and it's something that will be fixed in future parsers. Keeping backward compat right now doesn't give us much choice until the next major release which will break the current parser. I think this is the lesser of two evils, for now. |
+1 What's the current progress on this? I am currently struggling with schema Update: I was able to enhance my schemas using |
+1 |
@blakeembrey +1 blocked by this issue. Any progress on this? |
@martnst How you were able to achieve that outside of raml-js-parser? |
@dmartinezg @blakeembrey I have to keep my schemas (i have a lot!) in different folders, so this issue is very important for me. I can add some additional setting I can make pull request & tests with resolving referenced schemas without changing current interface of parser, so no one will be affected. Please let me know if it is that acceptable solution. If it is, i will make pull request. |
I have a rather complex setup include forks of dependencies here and there. Basically I have a node script that wraps everything up. It's all in the context of raml2hml. Therefor I am not sure my solution would help. |
@alvassin I do not work on this project anymore, @dmartinezg should be able to help you out. It sounds reasonable though. |
@alvassin, yes, if you can add the feature flag, we would be able to accept the patch. |
I don't think it would be that simple to do while loading the document, because at that stage, the actual root Instead of doing this step in the YAML loading (in The only remaining issue is handling the async nature of dereferencing the files, so maybe, the bit that Makes sense @alvassin ? |
@dmartinezg Thanks for suggestion! I'll update code and add additional tests 👍 |
@dmartinezg I implemented one more stage, that works after all fragment files are loade, but before composer (i would like to provide to composer ready object model for further validation & processing) - by adding one more Currently all cases are fine except inline defined schemas with E.g. for call I found issue, where is said that json-schema-ref-parser itself does not provide ability to pass path for resolving I could change process.cwd (only) for the dereferencing stage, and then returning its value back. Is that acceptable? |
As long as all !included files have been already de-referenced and parsed, I don't see an issue with cwd (I think) |
The problem is not with |
Need to add the ability to get the actual !include path for schemas.
The text was updated successfully, but these errors were encountered: