Join GitHub today
Add failing test for cyclic allOf + $ref in resolve subtree #1275
Here we are again.. I spent about two days this week on this issue and still haven't struck at the heart of it.
I'm punting again so I can land some related fixes for tonight's release - they're in the same branch, so I'll need to graft them out.
This will be at the top of my list.... Monday.
Swagger-Client #1275 notes for week of Monday, April 23
$ref plugin frames:
ok - it is an object inheritance issue.. but it's not an accident. when parsing replace patches when meta patching enabled, we break inheritance before replacing the target location so we can place metadata at the target without it also appearing at the source.
disabling that functionality is a bad idea, for a few reasons... (a) a worse user experience and a breaking change, (b) breakage of quite a few tests, and (c) likely to cause strange adverse behavior in Swagger-UI.
so that leaves us to work in the other direction - if we can't make specmap's internals more optimistic, we have to make the traverser more pessimistic.
this patch is being considered a mutation, so traverse is walking the mutation's value through the plugins without ever actually applying the mutation patch itself.
because the mutation patch disappears, but the patches generated from that mutation persist, the application of the generated patches fail.
$ref frame #4 yields no patches - this appears to be causing the mutation patch drop, while its derivatives hang around.
The solution was to update specmap's internal mutation applier to also break inheritance when meta patching is enabled. This keeps both sides of the system in harmony, avoiding the generation of patches for mutations that have not yet actually been applied but have bled through in specmap state due to inheritance.
Note that we also dropped testing for Node.js 4, since it reaches end-of-life this month (https://twitter.com/nodejs/status/968177367033229315). Going forward, we're testing Node.js 6, the latest LTS version,
I included the version changes in this PR because... the development experience polishing I did in the process of fixing this required a bump to webpack@3, which needs Node.js 6.