The anon class keeps a reference to the outer instance, which is irrelevant here but I figured it might become relevant as the code gets refactored in the future. This is the only reason I removed the anon class.

GraphQLArgument had previously only been found on a GraphQLFieldDefinition which itself could only been found on a GraphQLObjectType which is regular type. As a result, a type reference in an argument would only be possible within a hierarchy of another type. Now, a GraphQLArgument can be found directly on a directive which is not a real type. As a result, a type reference on an argument can be found outside of a hierarchy of a real type, thus it will not be in the schema's type map. And for those to be replaced correctly, directives need to be added as roots. This may result in a duplicated traversal in some cases (if the type of the directive argument is complex and has a reference inside, and does end up in the type map), but outside of a small performance hit, it has no negative consequences.

I guess it would also be possible for GraphQLTypeCollectingVisitor to also keep track of all top-level references in a separate collection. I'm personally OK with my current approach, but am open to changing it if you wish.

I see what you are proposing, but not sure I have good enough picture about possible use and edge cases.

Do we allow directives with same names and different arguments?
Can I have a directive, which accepts a complex type which has yet another directive and another type?
Will it matter to distinguish type traversal from traversal of a type under directive(s)?

Please bear with my questions, I will try to catch up with directives and clear my vision.
So far most simplest solution is probably the best strategy :)

• Directives with same names but different arguments - As far as I know, this is not allowed (same unique-name policy as with types). There might already be such a validation in place.
• Directives accepting complex types with further types and directives - Yes, I believe this is legit and is covered.
• Type traversal vs directive type traversal - I don't think there should be anything special about types under directives.

The edge cases I was referring to are mostly about type reference replacement. E.g. if a directive refers to a type found elsewhere in the schema, the reference must be replaced correctly. And vice versa, if another schema element referes to a type first defined on a directive it should work as usual. I tried to cover this in the tests.

For what it's worth, I've been using my fork for a few days now in rather complex scenarios (directives with complex types with references to other complex types with further directives) and it's behaving exactly as I'd expect.

But what I think is worth pointing out is that I don't change any rules in this PR. Everything doable with my changes is also doable without them. You can already add directives to anything, assign arguments of complex types, add further directives to those arguments etc.

All that the change does is make directives reachable by the traverser and, using that, make sure the reference replacement and type collection work in a consistent manner across schema elements.