Skip to content

feat(graphql): Add registerIn option for module-scoped type filtering#3811

Open
joe-re wants to merge 1 commit intonestjs:masterfrom
joe-re:introduce-register-in
Open

feat(graphql): Add registerIn option for module-scoped type filtering#3811
joe-re wants to merge 1 commit intonestjs:masterfrom
joe-re:introduce-register-in

Conversation

@joe-re
Copy link

@joe-re joe-re commented Jan 26, 2026

Add the ability to associate GraphQL types with specific NestJS modules using the new registerIn option. This enables type filtering when generating schemas for specific modules via the include option.

Motivation

When building multiple GraphQL endpoints with different schemas, developers need a way to control which types appear in each schema. Previously, only resolvers could be filtered by module - types were always included globally.

Changes

  • Add registerIn option to decorators:
    • @ObjectType, @inputType, @InterfaceType, @ArgsType
    • registerEnumType(), createUnionType()
  • Add RegisterInOption type (Function | (() => Function))
  • Add module filtering logic in TypeMetadataStorage
  • Add TypeDefinitionsStorage.clear() for multi-schema generation
  • Connect GqlModuleOptions.include to type filtering

Behavior

  • Types without registerIn: Included in all schemas
  • Types with registerIn: Included only when module is in include list

Example

@ObjectType({ registerIn: () => UsersModule })
class User { ... }

Notes

I followed @kamilmysliwiec's suggestion from #1432 (comment) and took over #1999 since it seems no progress recently. If you suggest any other solutions please let me know.

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Other... Please describe:

What is the current behavior?

Issue Number: #1999

When using the include option in GqlModuleOptions, only resolvers are filtered by module. All GraphQL types (ObjectType, InputType, InterfaceType, etc.) are always included in every schema regardless of module configuration.

What is the new behavior?

Types with registerIn option are only included in schemas where the specified module is listed in include. Types without registerIn remain globally available.

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

You can check how it work on the below repo.
https://github.com/joe-re/nestjs-graphql-register-in-sample

refs

#721 #1432

Add the ability to associate GraphQL types with specific NestJS modules
using the new `registerIn` option. This enables type filtering when
generating schemas for specific modules via the `include` option.

## Motivation
When building multiple GraphQL endpoints with different schemas,
developers need a way to control which types appear in each schema.
Previously, only resolvers could be filtered by module - types were
always included globally.

## Changes
- Add `registerIn` option to decorators:
  - @ObjectType, @inputType, @InterfaceType, @ArgsType
  - registerEnumType(), createUnionType()
- Add `RegisterInOption` type (Function | (() => Function))
- Add module filtering logic in TypeMetadataStorage
- Add TypeDefinitionsStorage.clear() for multi-schema generation
- Connect GqlModuleOptions.include to type filtering

## Behavior
- Types without `registerIn`: Included in all schemas
- Types with `registerIn`: Included only when module is in `include` list

## Example
```typescript
@ObjectType({ registerIn: () => UsersModule })
class User { ... }
```

## Notes
I followed @kamilmysliwiec's suggestion from nestjs#1432 (comment)
and took over nestjs#1999 since it seems no progress recently.
If you suggest any other solutions please let me know.

## Fixes
nestjs#1999, #14759
@joe-re joe-re force-pushed the introduce-register-in branch from 46b5ef3 to 0eed8e8 Compare January 26, 2026 15:25
@joe-re
Copy link
Author

joe-re commented Feb 6, 2026

@kamilmysliwiec I'd appreciate your review and feedback on this PR when you get a chance.
If you have a different direction in mind, feel free to close this — I'm happy to contribute to whatever approach works best. This is a real use case for me (running multiple schemas with different paths in a single process), so I'd love to help move it forward either way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant