Mirror of https://github.com/roostorg/coop
github.com/roostorg/coop
1overwrite: true
2hooks:
3 afterAllFileWrite:
4 - prettier --write
5schema: './server/graphql/**/*.ts'
6documents:
7 ['./client/src/**/*.tsx', './client/src/**/*.ts', './client/src/**/*.js']
8generates:
9 ./client/src/graphql/generated.ts:
10 plugins:
11 - typescript
12 - typescript-operations
13 - typescript-react-apollo
14 - named-operations-object
15 - add:
16 content:
17 - '/* eslint-disable */'
18 - 'import { JsonObject, JsonValue } from "type-fest";'
19 config:
20 fetcher:
21 endpoint: '"/api/v1/graphql"'
22 fetchParams:
23 headers:
24 Content-Type: application/json
25 immutableTypes: true
26 nonOptionalTypename: true
27 useTypeImports: true
28 enumsAsConst: true
29 generateSuspenseQuery: false
30 # NB: on the client side, we can't use the built-in prefixing, since it
31 # only supports types + document variables + fragments (e.g., there's no
32 # option for prefixing hook names.
33 # TODO: do we even need all these prefixes client-side, given that the
34 # client will eventually have (more or less) only GQL types?
35 # typesPrefix: 'GQL'
36 # documentVariablePrefix: 'GQL'
37 # fragmentVariablePrefix: 'GQL'
38 namingConvention:
39 typeNames: ./scripts/add_graphql_prefix.ts
40 scalars:
41 Date: Date | string
42 DateTime: Date | string
43 Cursor: string
44 JSON: JsonValue
45 JSONObject: JsonObject
46 CoopInputOrString: string
47 StringOrFloat: string | number
48 NonEmptyString: string
49 ./server/graphql/generated.ts:
50 plugins:
51 - typescript
52 - typescript-resolvers
53 - add:
54 content:
55 - '/* eslint-disable */'
56 - 'import { JsonObject, JsonValue } from "type-fest";'
57 config:
58 immutableTypes: true
59 # __typename is only a field on output types (not input types,
60 # interestingly, which ig is b/c GQL doesn't support input unions) and, on
61 # the backend, we only _produce_ output types (from resolvers) and never
62 # inspect them (like the client does). so, the effect of making __typename
63 # optional on the backend is to control whether our resolvers have to
64 # return objects with a __typename property. The runtime reality is that a
65 # __typename is needed iff the resolver returns a union type; if the
66 # schema specifies that the resolver can only return a single type, then
67 # apollo can fill in the __typename automatically. Unfortunately, there's
68 # no way (I think) to reflect that conditional rule in the config here, so
69 # we have to either require a __typename always, which leads to some
70 # boilerplate in cases where it wouldn't have been necessary, or make it
71 # always optional, which leads to potential runtime errors if its missing.
72 # Since those runtime errors should be pretty obvious during testing, we
73 # opt for less boilerplate over full safety.
74 nonOptionalTypename: false
75 useTypeImports: true
76 enumsAsConst: true
77 typesPrefix: 'GQL'
78 scalars:
79 Date: Date | string
80 DateTime: Date | string
81 Cursor: JsonValue
82 JSON: JsonValue
83 JSONObject: JsonObject
84 CoopInputOrString: string
85 StringOrFloat: string | number
86 NonEmptyString: NonEmptyString
87 contextType: ./resolvers.js#Context
88 # this override of maybe's definition needed to make optional resolver/query
89 # return types work correctly.
90 maybeValue: 'T extends Promise<infer U> ? Promise<U | null> : T | null'
91 # Don't change this; it makes type checking too permissive.
92 allowParentTypeOverride: false
93 mappers:
94 CustomAction: ../services/moderationConfigService/types/actions.js#CustomAction
95 EnqueueToMrtAction: ../services/moderationConfigService/types/actions.js#EnqueueToMrtAction
96 EnqueueToNcmecAction: ../services/moderationConfigService/types/actions.js#EnqueueToNcmecAction
97 EnqueueAuthorToMrtAction: ../services/moderationConfigService/types/actions.js#EnqueueAuthorToMrtAction
98 Backtest: ../models/rules/BacktestModel.js#Backtest
99 ContentType: ../models/rules/ItemTypeModel.js#ItemType
100 DerivedFieldSource: ../services/derivedFieldsService/helpers.js#DerivedFieldSpecSource
101 HashBank: ../models/HashBankModel.js#HashBank
102 Org: ../models/OrgModel.js#Org
103 # NB: for now we always resolve MatchingBanks with an Org model, and
104 # then call methods on the org model to resolve the sub-fields. This is
105 # a bit unusual, as matchingBanks could in theory be a standalone type,
106 # so we might have to expand this later.
107 MatchingBanks: ../models/OrgModel.js#Org
108 User: ../models/UserModel.js#User
109 LocationBank: ./datasources/LocationBankApi.js#LocationBankWithoutFullPlacesAPIResponse
110 # TODO(Kysely migration): these parents will flip to
111 # `../models/rules/ruleTypes.js#Rule` once the Action/Policy resolvers
112 # and the remaining Sequelize-backed callers of `org.getRules()` /
113 # `user.getFavoriteRules()` are migrated off Sequelize. Until then the
114 # GraphQL Rule parent is the Sequelize instance type, and
115 # `buildGraphqlRuleParent` casts to it at the boundary.
116 Rule: ../models/rules/RuleModel.js#Rule
117 Condition: ../services/moderationConfigService/index.js#Condition
118 ConditionWithResult: ../models/rules/RuleModel.js#ConditionWithResult
119 ConditionSet: ../services/moderationConfigService/index.js#ConditionSet
120 ConditionSetWithResult: ../models/rules/RuleModel.js#ConditionSetWithResult
121 LeafCondition: ../services/moderationConfigService/index.js#LeafCondition
122 LeafConditionWithResult: ../models/rules/RuleModel.js#LeafConditionWithResult
123 UserRule: ../models/rules/RuleModel.js#Rule
124 ContentRule: ../models/rules/RuleModel.js#Rule
125 RuleInsights: ../models/rules/RuleModel.js#Rule
126 Notification: ../services/notificationsService/notificationsService.js#Notification
127 Signal: ../services/signalsService/index.js#Signal
128 ManualReviewJobPayload: ../services/manualReviewToolService/index.js#ManualReviewJobPayload
129 ThreadManualReviewJobPayload: ../services/manualReviewToolService/index.js#ThreadManualReviewJobPayload
130 ContentManualReviewJobPayload: ../services/manualReviewToolService/index.js#ContentManualReviewJobPayload
131 UserManualReviewJobPayload: ../services/manualReviewToolService/index.js#UserManualReviewJobPayload
132 NcmecManualReviewJobPayload: ../services/manualReviewToolService/index.js#NcmecManualReviewJobPayload
133 ThreadAppealManualReviewJobPayload: ../services/manualReviewToolService/index.js#ThreadAppealReviewJobPayload
134 ContentAppealManualReviewJobPayload: ../services/manualReviewToolService/index.js#ContentAppealReviewJobPayload
135 UserAppealManualReviewJobPayload: ../services/manualReviewToolService/index.js#UserAppealReviewJobPayload
136 NonEmptyString: ../utils/typescript-types.js#NonEmptyString
137 ManualReviewQueue: ../services/manualReviewToolService/index.js#ManualReviewQueue
138 # NB: ItemBase only exists in GQL to make the fragments a bit DRYer
139 # (e.g., not have to repeat every field in `... on XXXItem` for every
140 # kind of item, in cases where we don't care about the item's type).
141 Item: ./types.js#ItemSubmissionForGQL
142 ItemBase: ./types.js#ItemSubmissionForGQL
143 # Our internal TS ItemType union type includes all the different kinds
144 # of ItemTypes, just like the GQL ItemType union does. Accordingly, it's
145 # safe to say that, wherever a resolver is for an ItemTypeBase GQL type,
146 # it'll actually have an ItemType (or ItemTypeSelector) as its input.
147 # Like ItemBase, ItemTypeBase only exists in GQL to make the fragments
148 # a bit DRYer.
149 ItemType: ../graphql/modules/itemType.js#ItemTypeResolversParentType
150 ItemTypeBase: ../graphql/modules/itemType.js#ItemTypeResolversParentType
151 ThreadItemType: ../graphql/modules/itemType.js#ThreadItemTypeResolversParentType
152 UserItemType: ../graphql/modules/itemType.js#UserItemTypeResolversParentType
153 ContentItemType: ../graphql/modules/itemType.js#ContentItemTypeResolversParentType
154 # This has to be here, not in `enumValues`, because of this bug https://github.com/dotansimha/graphql-code-generator/issues/9520
155 ItemTypeSchemaVariant: ../graphql/modules/itemType.js#ItemTypeSchemaVariantResolverValue
156 ItemTypeSchemaVariantInput: ../graphql/modules/itemType.js#ItemTypeSchemaVariantInputResolverValue
157 ReportingInsights: ../graphql/modules/reporting.js#ReportingInsights
158 ReportingRule: ../services/reportingService/ReportingRules.js#ReportingRuleWithoutVersion
159 RoutingRule: ../services/manualReviewToolService/modules/JobRouting.js#RoutingRuleWithoutVersion
160 ManualReviewJobComment: ../services/manualReviewToolService/modules/CommentOperations.js#ManualReviewJobComment
161 UserItem: ./types.js#ItemSubmissionForGQL
162 UserHistory: ../graphql/datasources/InvestigationApi.js#UserHistoryForGQL
163 ManualReviewJob: ../services/manualReviewToolService/index.js#ManualReviewJobOrAppeal
164 SignalWithScore: ../services/analyticsQueries/RuleActionInsights.js#SignalWithScore
165 ReportingRuleInsights: ../services/reportingService/ReportingRules.js#ReportingRuleWithoutVersion