Sibling errors should not be added after propagation

[yaacovCR]

Implementation of:

graphql/graphql-spec#1184

@benjie

[benjie]

This looks pretty good, minimal additional memory cost, reasonably efficient checks for existing errors, and zero cost if errors don't occur. The main memory cost is retaining path objects beyond their previous lifecycle, but that's incredibly marginal unless you have millions of errors - and if that's the case you have bigger issues.

Let's make hasNulledPosition more efficient, but that's my only requested change. WDYT, @JoviDeCroock?

[vercel]

@yaacovCR is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel.

A member of the Team first needs to authorize it.

review suggestion merged!

[benjie]

My one concern with this is that in future iteration people may not know to update errors and errorPositions concurrently.

Can we add a method to execution context to register errors instead (e.g. exeContext.addError(error, path)) and mark errors and errorPositions as readonly in ExecutionContext to discourage alternative manipulation?

added CollectedErrors utility class

[yaacovCR]

@benjie i added a CollectedErrors utility class to more tightly couple errors and errorPositions