ardatan / ardatan/graphql-tools
[graphql-tools/load] `loadDocuments` different error strategies
- Dominant language
- TypeScript
- Stars
- 5.4k
- Forks
- 830
- Avg merge
- 10h 59m
- Merged PRs (30d)
- 45
Description
**Is your feature request related to a problem? Please describe.**
Currently, if one of the GraphQL documents loaded via `loadDocuments` is invalid (e.g. raises a parse error), a single `GraphQLError` instance is thrown.
However, it might be useful to sometimes have:
- access to all the failed parsing errors
- access to the successfully parsed documents and the failed parsed documents
**Describe the solution you'd like**
Introduce different "load error behaviors" that alter the error handling. This could be done by a property that is passed to the `loadDocuments` function.
**Raise first error as it happens (current behaviour)**
```ts
const documents = await loadDocuments(['packages/**/*.graphql', 'packages/**/*.ts(x)'], {
loaders: [new GraphQLFileLoader(), new CodeFileLoader()],
errorBehaviour: 'legacy' // !!! better name recommendations welcome!!!
});
```
**Raise all errors as AggregateError**
```ts
const documents = await loadDocuments(['packages/**/*.graphql', 'packages/**/*.ts(x)'], {
loaders: [new GraphQLFileLoader(), new CodeFileLoader()],
errorBehaviour: 'aggregate'
});
```
**Do not raise an error at all, but instead include error in the return result**
```ts
const documents = await loadDocuments(['packages/**/*.graphql', 'packages/**/*.ts(x)'], {
loaders: [new GraphQLFileLoader(), new CodeFileLoader()],
errorBehaviour: 'ignore'
});
documents[0].document // this is null
documents[0].error // this is a GraphQLError
```
**Describe alternatives you've considered**
So far there is no alternative solution except re-implementing the function from scratch for each use case.
Contributor guide
Research direction
Start at the loadDocuments entry point and inspect how the GraphQLFileLoader and CodeFileLoader results are currently handled. Define the option semantics for legacy, aggregate, and ignore behavior, including how failed and successfully parsed documents are represented; the issue names no files or tests, so the implementation locations must be traced from this entry point.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100