Open ducin opened 6 years ago
Hi @ducin! This does look like a bug to me. I won't have time to look at it in the near future, but am happy to look over any PRs you send over.
I also ran into this. @bcherny do you think you might point to specific parts of the code where $ref
get resolved?
I have the same problem untfortunately. I would be willing to dig into this, however a starting point would be really nice to have
It looks like the issue is that the dereference
function from json-schema-ref-parser
doesn't supply any information about the original definitions.
As a result, the standaloneName
property on the AST is undefined for each interface (or arg or ast-param or however you want to call it).
Finally, they don't get declared as interface in the resulting declaration file because the name is lost.
If I supply a standaloneName
manually during debugging, it works fine...
I previously worked around this by re-declaring the definitions in the extended schema and adding a reference for each interface.
I now found a better workaround which is to set the id
property on each definition you want to generate an interface for.
Whatever you have assigned to id
will be the name of the interface.
⚠️ Note don't confuse this with the $id
property which can be used for references
In the above example this would look like this:
...
"Money": {
"id": "Money",
"type": "object",
"properties": {
"amount": {
....
},
...
This also fixes an issue where some interfaces would disappear when adding a comment to them 😅
I prepared a fix (see links above). However, it depends on the pull request from json-schema-ref-parser (also linked above). Until the PR is submitted and a new version is released, I won't create a pull request for this fix, since it would have no effect.
Hi @bcherny,
Once again, thanks for your great work!
I'm having a strange situation, might be considered as a bug, or a feature... depends on your interpretation. For me it's kinda inconsistent.
I have a
scenario.schema.json
file where I define an entity, it has internal sub-definitions (used for money, enums, etc.). It looks like the following:I have another file which is just a collection of these entities:
. I use both files in a RAML contract (generating html docs with
raml2html
and .d.ts files with your lib here). They need separate schema files, sinceGET /scenarios
is different thanGET /scenarios/{id}
.For a single
scenario
schema I get following:whereas for array with external reference, I get:
Semantically (from TS point of view), the structures are the same. However, internal references get normalized and "compiled into" the external file. I think it would be better if you normalized schemas after all
$ref
get resolved (no intermediate resolutions along the way).What is your opinion on this?