# DependencyFor() function · @imqueue/type-graphql-dependency

Source: https://imqueue.org/api/type-graphql-dependency/latest/type-graphql-dependency.dependencyfor/
Published: 2026-07-31
Author: @imqueue maintainers (https://github.com/imqueue)
Package: @imqueue/type-graphql-dependency 3.0.3 — generated reference, not hand-written

Class decorator declaring how a `type-graphql` entity is loaded and what it depends on, wiring it into `@imqueue/graphql-dependency`.

**Signature:**

```typescript
export declare function DependencyFor<T>(options: DependsOptions<T>): (target: any) => void;
```

## Parameters


| Parameter | Type | Description |
| --- | --- | --- |
| options | [DependsOptions](https://imqueue.org/api/type-graphql-dependency/latest/type-graphql-dependency.dependsoptions/)<T> | the loader, requirements and initializer to declare |


**Returns:**

(target: any) => void

the class decorator to apply

## Remarks

Applying it does not wire anything. It registers a hook on [schemaHooks](https://imqueue.org/api/type-graphql-dependency/latest/type-graphql-dependency.schemahooks/), because the `GraphQLObjectType` the class becomes does not exist while the decorator runs. The declarations only reach the engine once the application passes the built schema to those hooks.

That deferral moves every validation failure to the same later moment. Inside the hook, a `TypeError` is raised for a class that is not a GraphQL object type in the schema, a relation whose `as` names no field on it, or a `filter` naming a field on neither side. Running the hooks during boot rather than lazily is what turns these into start-up failures instead of per-request ones.

It works with both decorator conventions: the legacy `experimentalDecorators` form and standard TC39 decorators. Only the class name is read and nothing is returned, so both behave identically.

## Example


```typescript
// Consumer owns a list of ApiKey objects, loaded in bulk
@DependencyFor<Partial<Consumer>>({
    require: [
        [() => ApiKey, [
            // attach to Consumer.apiKeys; filter api keys by consumerId,
            // feeding it each consumer's own id
            { as: 'apiKeys', filter: { consumerId: 'id' } },
        ]],
    ],
    // pre-fills fields the requirement filters need; every dependency of
    // Consumer waits for it, since the fields it fills are not declared here
    async init(
        context: Context,
        result: Partial<Consumer>[],
        fields?: FieldsInput,
    ): Promise<DataInitializerResult> {
        return keyById(await context.consumer.enrich(result));
    },
    // how other entities load Consumer when they require it
    async load(
        context: Context,
        filter: ConsumerListInput,
        fields?: FieldsInput,
    ): Promise<Partial<Consumer>[]> {
        const { data } = await context.consumer.listConsumer(filter, fields);

        return toConsumers(data);
    },
})
@ObjectType()
export class Consumer {
    // ... field definitions ...
}
```