Mirror of https://github.com/roostorg/coop github.com/roostorg/coop
0
fork

Configure Feed

Select the types of activity you want to include in your feed.

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