@truxie/bullmq

BullMQ queues and workers for truxie: @Processor / @Process decorators, injectable queues, and worker discovery at bootstrap.

npm install @truxie/bullmq bullmq

@Module({
  imports: [
    BullModule.forRoot({connection: {host: 'localhost', port: 6379}}),
    BullModule.registerQueue({name: 'mail'}),
  ],
  providers: [MailProcessor],
})
export class AppModule {}

@Processor('mail')
class MailProcessor extends WorkerHost {
  async process(job: Job) { … }
}

@Injectable()
class MailService {
  constructor(@InjectQueue('mail') private readonly queue: Queue) {}

  send(to: string) { return this.queue.add('send', {to}) }
}

The connection belongs to configuration

Which is what forRootAsync is for — and the usual way to wire this in anything but a demo:

BullModule.forRootAsync({
  inject: [ConfigService],
  useFactory: (config: ConfigService) => ({connection: config.redis()}),
})

registerQueue reads the connection from whatever forRoot/forRootAsync resolved, so a queue declared in a feature module needs no connection details of its own. Queue tokens are keyed on the name through the global symbol registry, so several modules registering 'mail' all receive the same Queue instance.

bullmq is a peer dependency: this package does not choose its version for you, and installing truxie no longer implies a queue library.