-
-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Expected OgmaCoreModule to be configured by at last one Module but it was not configured within 0ms #228
Comments
Can you provide a minimum reproduction? |
@jmcdo29 it's related to register Another way to make it work is workaround {
...
providers: [
{
provide: createRequestScopedProviderToken(SomeService.name),
useValue: jest.fn()
}
]
} (It's for request scoped providers, if you would like to use not request scoped use |
It's probably related to dependency |
I did that now, the error is gone, but there is no log at all. I added some console logs to |
In version 0.3.0 and on, the interceptor is no longer auto attached. This is to allow for better customization of the request id generation. From the README for @ogma/nestjs-module
|
So, the interceptor works now, but the main issue is still there. I also made a codesandbox where you can reproduce it. On the left navigation bar, go to the https://codesandbox.io/s/nest-typescript-starter-forked-ofwpb?file=/src/app.module.ts I also included the It's logging in the |
@Ponjimon in the future, GitHub repositories are preferable to codesandbox reproductions. I noticed in your package.json you had several I was able to reproduce the bug, and have a workaround for the time being. I never really anticipated anyone to move the import { Module } from '@nestjs/common';
import { APP_FILTER, APP_INTERCEPTOR } from '@nestjs/core';
import { OgmaModule, OgmaModuleOptions } from '@ogma/nestjs-module';
import { ExpressParser } from '@ogma/platform-express';
import { GraphQLParser } from '@ogma/platform-graphql';
import { AppService } from 'app.service';
import { GqlHttpExceptionFilter } from './gql-http-exception.filter';
import { LoggingInterceptor } from './logging.interceptor';
export const OGMA_MODULE_OPTIONS: OgmaModuleOptions = {
service: {
color: Boolean(process.env.IS_OFFLINE),
},
interceptor: {
http: ExpressParser,
gql: GraphQLParser,
},
};
@Module({
imports: [
OgmaModule.forFeature(AppService),
OgmaModule.forRootAsync({
useFactory: (): OgmaModuleOptions | Promise<OgmaModuleOptions> =>
OGMA_MODULE_OPTIONS,
}),
],
providers: [
{ provide: APP_INTERCEPTOR, useClass: LoggingInterceptor },
{ provide: APP_FILTER, useClass: GqlHttpExceptionFilter },
],
exports: [OgmaModule]
})
export class LoggerModule {} Creating the I'll see what I can do to make this a better dev experience. I'm thinking I may just have to write the dynamic module myself and not use the |
That's a bummer, having to do that inside the LoggerModule makes the whole purpose of that module obsolete because that creates a circular dependency ModuleThatUsesLogger <=> LoggerModule. Thanks anyway, hopefully, this can be fixed in a future update. The reason I did it that way was because I am using this LoggerModule in many Nest applications and not just one, so I wanted to reduce code (duplication). |
To finally circle back around to this, I'm gonna work on phasing out the usage of |
The log methods now accept an object instead of multiple parameters to allow for the passing of extra keys. These keys can be anything, from cloud-provider to anything else you want to add. There's also a lot of refactoring and making some new interfaces for cleaner passing of parameters BREAKING CHANGE: log methods now take an object as the second parameter instead of having 3 extra optional parameters fix #215 #228 #297
The log methods now accept an object instead of multiple parameters to allow for the passing of extra keys. These keys can be anything, from cloud-provider to anything else you want to add. There's also a lot of refactoring and making some new interfaces for cleaner passing of parameters BREAKING CHANGE: log methods now take an object as the second parameter instead of having 3 extra optional parameters fix #215 #228 #297
Added to v0.4.0. This will most likely be the last pre v1 version. Thanks for the idea |
The log methods now accept an object instead of multiple parameters to allow for the passing of extra keys. These keys can be anything, from cloud-provider to anything else you want to add. There's also a lot of refactoring and making some new interfaces for cleaner passing of parameters BREAKING CHANGE: log methods now take an object as the second parameter instead of having 3 extra optional parameters fix #215 #228 #297
Bug Report
I get the above error when running
^0.2.2
and above but not with^0.1.0
I cannot find any breaking change about this?
Current behavior
The app doesn't start because of that error.
Expected behavior
It should start.
Environment
The text was updated successfully, but these errors were encountered: