[Nest.js Reflector] Bun resolve dependencies problem

[Dugnist]

What version of Bun is running?

1.0.35+940448d6b

What platform is your computer?

Darwin 22.5.0 arm64 arm

What steps can reproduce the bug?

I installed dependencies in my Nest.js project using Bun. Everything works without errors until I connect any guard that uses Nest.js Reflector.

For example, when I connect a guard for rate-limit:

import { ThrottlerGuard } from '@nestjs/throttler';
...
@UseGuards(ThrottlerGuard)

Then I get an error like this:

Nest can't resolve dependencies of the ThrottlerGuard (THROTTLER:MODULE_OPTIONS, Symbol(ThrottlerStorage), ?). Please make sure that the argument Reflector at index [2] is available in the AuthModule context.

Potential solutions:
- Is AuthModule a valid NestJS module?
- If Reflector is a provider, is it part of the current AuthModule?
- If Reflector is exported from a separate @Module, is that module imported within AuthModule?
  @Module({
    imports: [ /* the Module containing Reflector */ ]
  })

The same error occurs with other guards: cache-module-issue

What is the expected behavior?

The guards connection should work as described in the documentation and without errors.

What do you see instead?

A bug that Nest.js doesn't automatically connect Reflector with

import { Reflector } from '@nestjs/core';

to guards

Additional information

Here I am attaching an archive with a clean project and an example for testing:

empty_starter.zip

[Dugnist]

Everything works if I create my own separate class for the guard and do Inject Reflector directly in my guard. But it should work without this "hack".

[kodmanyagha]

Same problem occuring in ScheduleModule too.

[yharaskrik]

Also receiving this. @Jarred-Sumner I know you like to know about production use cases. Us at Trellis.org are trying to switch our Nx monorepo over to using Bun as the package manager and this is currently blocking (happens when I am dockerizing our nest APIs). Just so you have an idea of scope of use our monorepo 6 Nest APIs, 6 Angular apps and 3 Lambda functions plus using it for running all of our e2e tests, unit tests, etc. Would love to go all in on bun!

[yharaskrik]

Also receiving this. @Jarred-Sumner I know you like to know about production use cases. Us at Trellis.org are trying to switch our Nx monorepo over to using Bun as the package manager and this is currently blocking (happens when I am dockerizing our nest APIs). Just so you have an idea of scope of use our monorepo 6 Nest APIs, 6 Angular apps and 3 Lambda functions plus using it for running all of our e2e tests, unit tests, etc. Would love to go all in on bun!

Ok after some more initial investigation I got it to work, but not in a way I am a fan of. Here is what I am doing:

1. As part of our Nest API compilation process we generate a package.json that is a direct subset of our root package.json (the one the bun lockfile is for)
2. When dockerizing our app I ran bun install --frozen-lockfile but that errored saying the lockfile needed to be updated (this worked fine with yarn prior, I was able to use the root yarn.lock with the apps generated package.json in /dist)
3. So I remove the frozen lockfile flag and of course installation worked fine but then I got the error this thread is for.
4. By not even copying the lockfile in and just running bun install with the generated package.json it all seemed to work (but now I cannot guarentee the same versions are being used in prod vs the repo)
5. One thing I could do is enforce in our package.json that all packages do not have a ^ or ~ to get around this so then I would know that without the lockfile the versions are static.

Hopefully that is helpful!

[mrfullset]

Issue with ScheduleModule was resolved with rm -rf node_modules/ bun.lockb && bun i. Thanks.