Andrew Powell
Andrew Powell
Thanks for the PR. This looks like a breaking change since the output will change significantly. I would like to get eyes on this from @guybedford and @lukastaegert before we...
@bluwy can we get that `strictRequires` change into here as well?
@lukastaegert since this affects the entire repo and assets we publish for the entire repo, I'd like your stamp on this before w emerge. @Andarist @tada5hi you two as well...
Closing as abandoned.
@MichalLytek not being able to use `graphql@16` is starting to become a major blocker. All of the tools based on `graphql` are starting to leverage it and we're finding that...
> Moreover, in https://github.com/MichalLytek/type-graphql/pull/1400, all runtime errors now extends GraphQLError and have additional information in extensions field (i.e. validationErrors for ArgumentValidationError) @carlocorradini I don't see any changes in #1400 around...
> All these errors extends GraphQLError great, those should be fine. > If you really want to hide them, just catch the error and return a more generic one. That's...
I didn't imply that there was, perhaps that's a language barrier issue. > error handling is done in/by the server and not in the "logic". While I understand that you...
> For production and safe usage, you can use formatError, do simple instance of checks and filter all the fragile data, even returning generic "Internal Server Error" with no stack...
> That seems a little out of scope It's contextually out of scope by default. But it's absolutely not out of scope for most users of PNPM (hey there, I'm...