Patrick Arminio

do you think it is worth moving flake8 to pre-commit?

@jkimbo @DoctorJohn do you remember why we didn't send these errors to the response object? /cc @erikwrede do you have any opinion on this? Context: https://github.com/strawberry-graphql/strawberry/pull/1324

> Hey @staubina, with our current implementation this seems to be expected. > > You might want to try to add your validation error to the execution context, similar to...

> After looking at it again, I believe we should handle all errors the same, no matter if they originate in the extension or in the resolver. The detailed decision...

for reference, this is how I did something similar, not sure if it is the best way: ```tsx "use client"; import { ApolloLink, HttpLink } from "@apollo/client"; import { setContext...

oh that's a cool suggestion! how would this work? would you pass the old SDL and figure the breaking changes from there?

So something like this: ``` strawberry find-breaking-changes old-schema.graphql strawberry find-breaking-changes old-schema.graphql current-schema.graphql ``` we could do the same for find dangerous changes 🤔 or combine the two commands into one,...

maybe `strawberry audit` could be a good one, I was thinking about `strawberry lint` but that wouldn't make a lot of sense when passing an old schema happy to take...

Yet another option: Apollo also has a schema check feature: https://www.apollographql.com/docs/rover/commands/graphs/#graph-check

> Oh and I was gonna call it something like schema_check in my project 🙃 ah! to add more ideas, we could allow using pyproject.toml to specify the options, but...