feat: pass context to formatErrors

[JonathanCallewaert]

If you want to show different types of errors based on your context, for instance personalized errors based on the user (language) that has sent the request, ...

TODO:

• Update CHANGELOG.md with your change (include reference to issue & this PR)
• Make sure all of the significant new logic is covered by tests
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass

[apollo-cla]

@JonathanCA97: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[JonathanCallewaert]

@abernix , when is this PR going to be watched?

[tim-soft]

any blockers here? I'm very keen to see this merged @martijnwalraven @abernix

[JonathanCallewaert]

@martijnwalraven any blocking issues? I want to know why this isn't reviewed/accepted yet.

[fromthemills]

It would be very useful to have the context available in the format function.
Is there any way we can get this moving again? @abernix @JonathanCA97
An extra argument in a function seems like a reasonable (not breaking) change. Any blokkers I can help with?

[abernix]

I see the value you might gain by having this additional context argument, however, the formatError method is meant to match the function signature of the underlying graphql-js library, as defined here and for compatibility reasons, I think it should stay true to that signature.

That doesn't mean that there shouldn't be a way to accomplish what you're (likely) trying to do though and I'd encourage you to explore the new didEncounterErrors life-cycle hook which was introduced in #2719. There's a bit of an example of how to use it in #1709 (comment) which should allow you to react to the presence of errors with context-awareness. (There will be documentation added to #2008 for didEncounterErrors, but I hope that example does the trick for now.)

I think we should explore the possibilities of that new life-cycle hook. Keep in mind that it's possible to attach properties to an error object in didEncounterErrors and that property will eventually be present on the error received by formatError.

If this still doesn't work out, please open a new issue so we can come to a consensus on the best approach before moving into a PR. Ultimately, we'd like to have this be addressable within the request pipeline API.