Add name property to ApolloError

[aaronadamsCA]

Fixes #9322

Checklist:

• If this PR is a new feature, please reference an issue where a consensus about the design was reached (not necessary for small changes)
• Make sure all of the significant new logic is covered by tests

[apollo-cla]

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

[aaronadamsCA]

It looks like tests would need to be updated due to the effect this has on the error's toString; I can do that, as long as there's agreement it's the right thing to do.

The other option would be to set ApolloError's name to 'Error' but that doesn't seem right.

The one thing that seems worst is leaving it as-is, because the errors being thrown don't match the interface. For example, my code can't check if (error.name == null) in a type-safe way, because according to the types you're shipping, name is a non-optional property of type string.

[brainkim]

@aaronadamsCA I updated the snapshot tests and rebased against main. Thanks for looking into this.

The one thing that seems worst is leaving it as-is, because the errors being thrown don't match the interface. For example, my code can't check if (error.name == null) in a type-safe way, because according to the types you're shipping, name is a non-optional property of type string.

Can you clarify this point? What’s the use-case for error.name being null?

@benjamn Thoughts? Maybe can be fit into a 3.5 patch release?

[aaronadamsCA]

@aaronadamsCA I updated the snapshot tests and rebased against main. Thanks for looking into this.

The one thing that seems worst is leaving it as-is, because the errors being thrown don't match the interface. For example, my code can't check if (error.name == null) in a type-safe way, because according to the types you're shipping, name is a non-optional property of type string.

Can you clarify this point? What’s the use-case for error.name being null?

@benjamn Thoughts? Maybe can be fit into a 3.5 patch release?

Ah, this was just so I could patch name = "ApolloError" on my end so Sentry would stop freaking out; but I couldn't do that without ignoring the types. There are obviously far better real-world examples.

[jerelmiller]

This seems like a reasonable change to me. I'll get a CHANGELOG entry in place so we can get this in for v3.7.2. Thanks for your patience @aaronadamsCA!