[FEATURE] Logger #45
[FEATURE] Logger #45
Conversation
Fixes #37
📝 Walkthrough📝 WalkthroughWalkthrough이 변경 사항은 NestJS 애플리케이션에 로깅 기능을 추가하기 위한 여러 파일의 수정 및 추가를 포함합니다. 새로운 Changes
Assessment against linked issues
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Outside diff range and nitpick comments (13)
libs/logger/src/logger.module.ts (1)
5-9: 모듈 구조 개선이 필요합니다모듈이 올바르게 구성되어 있지만,
LoggerDecoratorRegister를 외부에서 사용할 수 있도록 exports에 추가하는 것이 좋습니다.다음과 같이 수정을 제안합니다:
@Module({ imports: [DiscoveryModule], providers: [LoggerDecoratorRegister], + exports: [LoggerDecoratorRegister], }) export class LoggerModule {}src/idp/idp.service.ts (2)
Line range hint
29-29: 보안 관련 로깅 레벨 조정 필요로그인 실패와 리프레시 토큰 누락과 같은 보안 관련 이벤트는
debug레벨 대신warn레벨로 기록하는 것이 좋습니다. 또한 이러한 이벤트에 대한 추가 컨텍스트(예: IP 주소, 시도 횟수 등)를 포함하는 것을 고려해주세요.-this.logger.debug(`login failed: ${email}`); +this.logger.warn(`Login attempt failed`, { email, timestamp: new Date() }); -this.logger.debug(`refreshToken not found: ${refreshToken}`); +this.logger.warn(`Invalid refresh token attempt`, { timestamp: new Date() });Also applies to: 30-30, 67-67, 68-68
12-14: 로깅 전략 통합 검토 필요
@Loggable()데코레이터와 수동 로깅이 함께 사용되고 있습니다. 로깅 전략을 다음과 같이 개선하는 것을 고려해주세요:
- 데코레이터를 통한 자동 로깅과 수동 로깅의 역할을 명확히 구분
- 로깅 레벨과 포맷에 대한 일관된 가이드라인 수립
- 보안 이벤트에 대한 특별한 로깅 정책 수립
src/user/user.repository.ts (1)
Line range hint
19-121: 에러 처리 패턴 개선 제안각 메소드에서 반복되는 에러 처리 로직을 공통 유틸리티 메소드로 추출하면 코드 중복을 줄일 수 있습니다.
다음과 같은 리팩토링을 제안합니다:
private handlePrismaError(error: unknown, context: string) { if (error instanceof PrismaClientKnownRequestError) { if (error.code === 'P2025' || error.code === 'P2002') { throw new ForbiddenException('존재하지 않는 유저입니다.'); } throw new InternalServerErrorException(); } throw new InternalServerErrorException(); }이 유틸리티 메소드를 사용하여 각 메소드의 catch 블록을 단순화할 수 있습니다.
src/oauth/oauth.repository.ts (3)
Line range hint
108-110: 필터 조건문에 심각한 오류가 있습니다.현재 구현된 필터 콜백 함수가 값을 반환하지 않아 모든 토큰이 필터링되지 않습니다. 또한 비교 연산자의 결과값이 사용되지 않습니다.
다음과 같이 수정해주세요:
- .filter(({ updatedAt }) => { - updatedAt >= boundaryDate; - }) + .filter(({ updatedAt }) => updatedAt >= boundaryDate)
Line range hint
57-57: 날짜 계산 로직에 오류가 있습니다.
new Date().getMonth() - 1은 단순히 월 숫자만 감소시키며, 정확한 한 달 전 날짜를 계산하지 않습니다. 이로 인해 잘못된 경계 날짜가 설정될 수 있습니다.다음과 같이 수정하는 것을 추천드립니다:
- const boundaryDate = new Date(new Date().getMonth() - 1); + const boundaryDate = new Date(); + boundaryDate.setMonth(boundaryDate.getMonth() - 1);
Line range hint
57-124: 리포지토리 계층의 책임 분리가 필요합니다.현재 리프레시 토큰 관리 로직이 리포지토리 계층에 직접 구현되어 있습니다. 이는 단일 책임 원칙(SRP)을 위반하며, 리포지토리 패턴의 모범 사례와 맞지 않습니다.
다음과 같은 개선을 제안드립니다:
- 토큰 관리 로직을 별도의 서비스 클래스로 분리
- 리포지토리는 순수한 데이터 접근 계층으로 유지
- 비즈니스 로직은 서비스 계층에서 처리
예시 구조:
@Injectable() class TokenManagementService { constructor(private readonly oauthRepository: OauthRepository) {} async updateRefreshToken(user: UserInfo, clientId: string, token: string, scopes: Readonly<Scope[]>): Promise<void> { // 현재 리포지토리에 있는 토큰 관리 로직을 이곳으로 이동 } }src/client/client.repository.ts (1)
Line range hint
1-201: 로깅 아키텍처 개선 제안현재 구현된 로깅 시스템에 대해 다음과 같은 아키텍처 개선사항을 고려해보시기 바랍니다:
- 로그 레벨 정책 수립
- 구조화된 로깅 포맷 정의
- 로그 집계 및 모니터링 전략
- 성능 메트릭스 수집 방안
이러한 요소들을 고려하여 로깅 시스템을 보완하면 운영 환경에서 더욱 효과적인 모니터링이 가능할 것 같습니다. 필요하시다면 상세한 아키텍처 가이드를 제공해드릴 수 있습니다.
src/client/client.service.ts (2)
18-21: 로깅 전략 재검토 필요현재 구현에서 다음 사항들을 고려해야 합니다:
@Loggable()데코레이터와 기존private readonly logger인스턴스가 중복되어 있습니다.- 데코레이터 기반 로깅과 수동 로깅 간의 관계가 명확하지 않습니다.
다음 사항들을 제안드립니다:
- 로깅 전략을 통일하여 하나의 접근 방식만 사용하는 것이 좋습니다.
- 데코레이터 기반 로깅을 사용한다면 기존 logger 인스턴스를 제거하는 것이 좋습니다.
- 각 방식의 장단점을 고려하여 프로젝트 전체적으로 일관된 로깅 전략을 수립해야 합니다.
아래 코드 변경을 고려해보세요:
@Injectable() @Loggable() export class ClientService { - private readonly logger = new Logger(ClientService.name); constructor( private readonly clientRepository: ClientRepository, private readonly httpService: HttpService, private readonly configService: ConfigService, ) {}
Line range hint
201-204: 에러 로깅 전략 일관성 확보 필요
validateClient메소드에서 수동 에러 로깅이 여전히 남아있습니다.@Loggable데코레이터를 사용하는 상황에서 에러 처리 방식이 일관되지 않습니다.다음 두 가지 방안 중 하나를 선택하여 일관성 있게 구현하는 것을 추천드립니다:
@Loggable데코레이터가 에러를 처리하도록 위임:const client = await this.clientRepository.findById(id).catch((error) => { - this.logger.error(`validateClient: error=${error}`); throw new UnauthorizedException('invalid_client'); });
- 또는 전역 예외 필터를 구현하여 모든 예외를 일관되게 로깅:
@Catch() export class GlobalExceptionFilter implements ExceptionFilter { catch(exception: unknown, host: ArgumentsHost) { // 전역 로깅 구현 } }src/user/user.service.ts (1)
민감한 정보 로깅 처리 개선 필요
현재 코드베이스에서 다음과 같은 보안 관련 문제점들이 발견되었습니다:
- 이메일 주소가 로그에 평문으로 노출되고 있습니다 (
user already exists: ${email},user not found: ${email}등)- 에러 객체가 직접 로그에 포함되어 있어 민감한 정보가 노출될 수 있습니다 (
error: ${error})@Loggable()데코레이터가 단순히 메타데이터만 설정하고 있어, 민감 정보 필터링 기능이 없습니다다음 사항들의 구현이 필요합니다:
- 이메일 주소 마스킹 처리 (예:
user***@domain.com)- 에러 객체 로깅 시 스택 트레이스 제외
- 민감 정보 필터링을 위한 로깅 인터셉터 추가
🔗 Analysis chain
Line range hint
1-217: 보안 로깅 정책 검토 필요이 서비스는 사용자 인증, 비밀번호 변경 등 민감한 작업을 처리합니다. 새로운 로깅 시스템이 이러한 민감한 정보를 적절히 처리하는지 확인이 필요합니다.
다음 사항들을 고려해주세요:
- 민감한 데이터의 로깅 제외 또는 마스킹 처리
- 로그 레벨의 적절한 설정
- 에러 처리 시 스택 트레이스 노출 제한
Let me gather more information about the logging implementation to provide a comprehensive response.
Based on the results so far, let me check one more aspect of the logging implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # 민감한 정보 로깅 패턴 검사 rg "this\.logger\.(debug|error|warn|info).*password" -A 2 rg "this\.logger\.(debug|error|warn|info).*email" -A 2 # Loggable 데코레이터의 보안 설정 확인 ast-grep --pattern '@Loggable({ $$$ })'Length of output: 2608
Script:
#!/bin/bash # Check Loggable decorator implementation ast-grep --pattern 'export class $_ { $$$ transform($$$) { $$$ } $$$ }' # Check for any logging configuration files fd -e ts -e js config rg "logger|logging" -g "*.config.ts" -g "*.config.js" # Check for any logging interceptors or filters rg "implements LoggerService|extends Logger" -A 5Length of output: 435
Script:
#!/bin/bash # Check the Loggable decorator implementation fd -t f -e ts decorator rg "export.*Loggable" -A 10 # Check for any logging middleware or interceptors fd -t f -e ts middleware interceptor rg "LoggingInterceptor|LoggingMiddleware" -A 5Length of output: 467
src/oauth/oauth.service.ts (1)
Line range hint
1-450: 보안 강화 권장사항OAuth 서비스 구현에서 다음과 같은 보안 개선사항을 고려해주세요:
- 토큰 만료 시간이 하드코딩되어 있습니다 (3600초). 이를 환경 변수로 관리하는 것이 좋습니다.
- 리프레시 토큰에 대한 만료 정책이 명확하지 않습니다.
- 토큰 재사용 탐지 메커니즘이 없습니다.
다음과 같은 개선사항을 제안드립니다:
- const tokenCache: TokenCacheType | undefined = await this.cacheService.get( - token, - { - prefix: this.TokenPrefix, - ttl: 3600, - }, - ); + const TOKEN_EXPIRY = this.configService.get<number>('TOKEN_EXPIRY_SECONDS', 3600); + const tokenCache: TokenCacheType | undefined = await this.cacheService.get( + token, + { + prefix: this.TokenPrefix, + ttl: TOKEN_EXPIRY, + }, + );또한 토큰 재사용 탐지를 위한 블랙리스트 메커니즘 구현을 검토해주세요.
libs/logger/src/logger.decorator.register.ts (1)
30-30: 각 클래스별로 Logger 인스턴스를 재사용하여 효율성 향상현재 각 메서드마다 새로운 Logger 인스턴스를 생성하고 있습니다. 동일한 클래스 내에서는 하나의 Logger 인스턴스를 재사용하면 성능 및 메모리 효율성을 높일 수 있습니다.
다음과 같이 수정하여 Logger 인스턴스를 재사용할 수 있습니다:
// forEach 문 상단에 Logger를 생성합니다 + const logger = new Logger(instance.constructor.name); this.metadataScanner .getAllMethodNames(instance) .forEach((methodName) => { - const logger = new Logger(instance.constructor.name); instance[methodName] = function (...args: any[]) { logger.log(`Before ${methodName}`); // ...
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (18)
.vscode/settings.json(1 hunks)libs/logger/src/decorator/loggable.ts(1 hunks)libs/logger/src/index.ts(1 hunks)libs/logger/src/logger.decorator.register.ts(1 hunks)libs/logger/src/logger.module.ts(1 hunks)libs/logger/tsconfig.lib.json(1 hunks)nest-cli.json(1 hunks)package.json(2 hunks)src/app.module.ts(2 hunks)src/client/client.repository.ts(1 hunks)src/client/client.service.ts(1 hunks)src/idp/idp.service.ts(1 hunks)src/oauth/oauth.repository.ts(1 hunks)src/oauth/oauth.service.ts(1 hunks)src/user/user.repository.ts(2 hunks)src/user/user.service.ts(1 hunks)test/jest-e2e.json(1 hunks)tsconfig.json(1 hunks)
✅ Files skipped from review due to trivial changes (3)
- .vscode/settings.json
- libs/logger/src/index.ts
- libs/logger/tsconfig.lib.json
🔇 Additional comments (19)
libs/logger/src/decorator/loggable.ts (1)
1-4:
로깅 기능 구현이 너무 단순합니다
현재 구현은 단순히 메타데이터만 설정하고 있습니다. Ziggle의 로거를 통합하기 위해서는 다음과 같은 기능들이 추가로 필요할 것 같습니다:
- 로그 레벨 설정
- 로그 포맷 설정
- 컨텍스트 정보 수집
- 에러 처리 로직
Ziggle의 로거 구현을 확인하기 위해 다음 스크립트를 실행합니다:
libs/logger/src/logger.module.ts (1)
1-9: Ziggle 로거 구현 확인이 필요합니다
PR 목적에 따르면 Ziggle 애플리케이션의 로거를 통합해야 하는데, 현재 구현에서는 해당 부분을 확인할 수 없습니다.
✅ Verification successful
Let me gather more information about the logger implementation.
Let me check for any logger-related decorators or interfaces that might be defined.
Let me check the Loggable decorator implementation since it appears to be used across multiple files.
로거 구현이 이미 완료되어 있습니다
현재 구현된 로거는 NestJS의 기본 Logger를 사용하여 메서드 실행 시간을 측정하고 로깅하는 기능을 제공합니다. @Loggable() 데코레이터를 통해 각 서비스의 메서드에 자동으로 로깅 기능이 적용되며, 다음과 같은 기능들이 구현되어 있습니다:
- 메서드 실행 전/후 로깅
- 실행 시간 측정
- 비동기 메서드 지원
- 클래스 이름 기반의 로거 컨텍스트
현재 user, oauth, idp, client 등 여러 서비스에서 이미 @Loggable 데코레이터를 사용 중입니다.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Ziggle 로거 구현 검색
# Ziggle 로거 관련 파일 검색
echo "Searching for Ziggle logger implementation..."
rg -l "Ziggle" --type ts
# 로거 관련 클래스 검색
echo "Searching for logger related classes..."
ast-grep --pattern 'class $_ implements Logger {
$$$
}'
Length of output: 274
Script:
#!/bin/bash
# Search for logger related files and implementations
echo "Searching for logger related files..."
fd "logger" --type f --extension ts
echo -e "\nSearching for logger implementations..."
rg "class.*Logger" -A 5 --type ts
echo -e "\nSearching for logger decorator implementations..."
rg "@Logger" -A 5 --type ts
echo -e "\nSearching for logger service implementations..."
ast-grep --pattern 'class $_ {
$$$
log($$$) {
$$$
}
$$$
}'
Length of output: 1189
Script:
#!/bin/bash
# Search for logger decorators and interfaces
echo "Searching for logger decorator definitions..."
rg "function.*Logger.*\(" --type ts -A 5
echo -e "\nSearching for logger interfaces..."
ast-grep --pattern 'interface $_ {
$$$
log($$$)
$$$
}'
echo -e "\nSearching for logger imports..."
rg "import.*logger" -i --type ts
Length of output: 1654
Script:
#!/bin/bash
# Search for Loggable decorator implementation
echo "Searching for Loggable decorator file..."
fd "loggable" --type f --extension ts
echo -e "\nSearching for Loggable decorator content..."
rg -p "export.*Loggable" -A 10 --type ts
echo -e "\nChecking logger decorator register implementation..."
cat libs/logger/src/logger.decorator.register.ts
Length of output: 2293
test/jest-e2e.json (2)
2-6: 코드 가독성이 개선되었습니다!
모듈 파일 확장자 배열의 포맷팅이 개선되어 가독성이 향상되었습니다.
13-15: logger 모듈 경로 설정을 확인해주세요.
logger 모듈에 대한 경로 매핑이 추가되었습니다. 다음 사항들을 확인해주세요:
- libs/logger/src 디렉토리가 실제로 존재하는지
- 매핑된 경로가 실제 프로젝트 구조와 일치하는지
경로 구성을 확인하기 위해 다음 스크립트를 실행합니다:
✅ Verification successful
logger 모듈 경로 설정이 정확히 구성되어 있습니다.
실행된 스크립트를 통해 다음 사항들이 확인되었습니다:
- libs/logger/src 디렉토리가 존재함
- 해당 디렉토리에 필요한 모듈 파일들(index.ts, logger.module.ts 등)이 포함되어 있음
- jest-e2e.json의 moduleNameMapper 설정이 실제 프로젝트 구조와 일치함
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the existence of logger module directory and its structure
# Check if the logger module directory exists
if [ -d "libs/logger/src" ]; then
echo "Logger module directory exists"
# List files in the logger module directory
fd . libs/logger/src -t f
else
echo "Error: Logger module directory not found"
exit 1
fi
Length of output: 268
nest-cli.json (1)
9-18: 로거 라이브러리 프로젝트 구조 검증 필요
NestJS 모노레포 구조에 맞게 로거 라이브러리가 설정되었습니다. 프로젝트 구조와 설정이 적절한지 확인이 필요합니다.
✅ Verification successful
Let me check the logger module implementation to ensure it follows NestJS best practices.
Let me check the decorator register implementation to complete the verification.
로거 라이브러리의 구조와 구현이 적절함을 확인했습니다
로거 라이브러리가 NestJS 모노레포 구조와 모범 사례를 잘 따르고 있습니다:
- 적절한 디렉토리 구조 (
src,decorator등) - 올바른 tsconfig 설정과 상속 관계
@nestjs/core의 DiscoveryModule을 활용한 메타데이터 기반 데코레이터 구현- 비동기/동기 메서드 모두 지원하는 로깅 기능
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify logger library structure and configuration
# Check if the library structure follows NestJS conventions
fd . libs/logger -t d
# Verify tsconfig exists and extends properly
cat libs/logger/tsconfig.lib.json
# Check for essential logger files mentioned in AI summary
fd . libs/logger/src -e ts
Length of output: 493
Script:
#!/bin/bash
# Check logger module implementation
cat libs/logger/src/logger.module.ts
# Check decorator implementation
cat libs/logger/src/decorator/loggable.ts
# Check index exports
cat libs/logger/src/index.ts
Length of output: 569
Script:
#!/bin/bash
# Check decorator register implementation
cat libs/logger/src/logger.decorator.register.ts
Length of output: 1760
tsconfig.json (1)
20-20: esModuleInterop 설정이 적절히 추가되었습니다.
CommonJS와 ES 모듈 간의 호환성을 보장하는 좋은 설정입니다.
src/app.module.ts (2)
12-12: @lib/logger 경로 설정 확인 필요
별칭(alias) 경로를 사용하고 있습니다. tsconfig.json 또는 webpack 설정에서 경로 매핑이 올바르게 구성되어 있는지 확인해주세요.
✅ Verification successful
@lib/logger 경로 설정이 올바르게 구성되어 있습니다
tsconfig.json의 경로 별칭 설정과 실제 프로젝트 구조가 정확히 일치합니다:
@lib/logger→libs/logger/src- LoggerModule이
libs/logger/src/logger.module.ts에 올바르게 구현되어 있음 - 모듈 구조와 내보내기가 정상적으로 설정됨
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify path alias configuration
# Check TypeScript config
echo "Checking tsconfig.json for path aliases:"
cat tsconfig.json | jq '.compilerOptions.paths'
# Check if the logger library exists
echo -e "\nChecking logger library location:"
fd -t f -g "*logger*" lib/
Length of output: 441
Script:
#!/bin/bash
# Check for logger files in libs directory instead of lib
echo "Checking logger files in libs directory:"
fd -t f -g "*logger*" libs/
# Check if the logger module exists and its structure
echo -e "\nChecking logger module structure:"
fd . libs/logger/src/
# Verify the module implementation
echo -e "\nChecking logger module implementation:"
cat libs/logger/src/index.ts 2>/dev/null || echo "index.ts not found"
cat libs/logger/src/logger.module.ts 2>/dev/null || echo "logger.module.ts not found"
Length of output: 942
28-28: LoggerModule 설정 검토 필요
LoggerModule이 기본 설정으로 추가되었습니다. Ziggle 애플리케이션의 로거와 동일한 동작을 보장하기 위해 추가 설정이 필요한지 확인해주세요.
✅ Verification successful
Let me gather more information about the logger configuration and usage.
Let me check the logger module implementation and configuration details.
LoggerModule 설정이 적절히 구성되어 있습니다
LoggerModule은 Ziggle 애플리케이션과 동일한 방식으로 구현되어 있습니다:
@Loggable()데코레이터를 통한 메서드 로깅- 메서드 실행 시간 측정
- 클래스 이름 기반의 로거 컨텍스트 자동 설정
추가 설정 없이 현재 구현으로 충분합니다.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check logger configuration and usage
# Look for logger configuration
echo "Checking for logger configuration:"
rg -A 5 "LoggerModule.(?:forRoot|register|configure)"
# Check Loggable decorator usage
echo -e "\nChecking Loggable decorator usage:"
ast-grep --pattern 'class $_ {
@Loggable()
$$$
}'
Length of output: 275
Script:
#!/bin/bash
# Search for any logger-related imports and configurations
echo "Checking logger imports and configurations:"
rg -l "Logger|LoggerModule"
# Search for logger service implementations
echo -e "\nChecking logger service implementations:"
ast-grep --pattern 'class $_ implements Logger'
# Check for any logger-related configuration files
echo -e "\nChecking for logger config files:"
fd -g "*logger*.{ts,js,json}"
# Look for any logging related environment variables
echo -e "\nChecking environment files for logger settings:"
fd -g ".env*" --exec cat {} \; | rg -i "log"
Length of output: 1218
Script:
#!/bin/bash
# Check logger module implementation
echo "Checking logger module implementation:"
cat libs/logger/src/logger.module.ts
# Check logger decorator implementation
echo -e "\nChecking logger decorator implementation:"
cat libs/logger/src/logger.decorator.register.ts
# Check for any logger configuration in app.module.ts
echo -e "\nChecking app module logger configuration:"
cat src/app.module.ts
Length of output: 3307
src/idp/idp.service.ts (1)
9-9: 로거 라이브러리 구성 확인 필요
@lib/logger 라이브러리가 올바르게 구성되어 있는지 확인이 필요합니다.
Also applies to: 12-12
✅ Verification successful
Let me verify the logger implementation further with additional scripts.
로거 라이브러리가 정상적으로 구성되어 있음을 확인했습니다
로거 구현이 다음과 같이 올바르게 되어 있습니다:
LoggerModule이 앱 모듈에 정상적으로 임포트되어 있습니다@Loggable데코레이터가 여러 서비스에서 일관되게 사용되고 있습니다- 로거 라이브러리가
libs/logger에 적절히 구현되어 있습니다
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify logger library configuration and implementation
# Check if logger library exists and is properly configured
fd -t f . "libs/logger" -x cat {} \;
# Check for other services using the Loggable decorator
ast-grep --pattern 'import { Loggable } from "@lib/logger/decorator/loggable"'
Length of output: 2506
Script:
#!/bin/bash
# Check for other services using the Loggable decorator with more context
rg -l "import.*Loggable.*from.*@lib/logger" -g "*.ts"
# Check if LoggerModule is imported in the app module
rg "LoggerModule" -g "*.module.ts"
# Check if there are any other logging implementations
rg "new Logger\(" -g "*.ts"
Length of output: 1475
package.json (4)
10-10: 포매팅 스크립트에 libs 디렉토리가 추가되었습니다.
libs 디렉토리의 TypeScript 파일들도 포매팅 대상에 포함되도록 수정되었습니다. 이는 새로운 로거 모듈의 코드 스타일 일관성을 유지하는데 도움이 됩니다.
104-105: 모듈 경로 매핑이 적절하게 추가되었습니다.
테스트와 로거 모듈에 대한 경로 매핑이 추가되었습니다. 이를 통해 Jest가 테스트 실행 시 모듈을 올바르게 찾을 수 있습니다.
109-112: Jest roots 설정이 적절하게 구성되었습니다.
src와 libs 디렉토리가 Jest의 루트 디렉토리로 추가되어, 로거 모듈의 테스트 파일도 올바르게 실행될 수 있습니다.
Line range hint 24-53: 로깅 관련 의존성 확인이 필요합니다.
현재 package.json에 로깅 관련 의존성이 명시적으로 추가되어 있지 않습니다. 기본 NestJS 로거를 사용하는 것인지, 아니면 추가 의존성이 필요한지 확인이 필요합니다.
✅ Verification successful
NestJS의 내장 Logger를 사용하고 있어 추가 의존성이 필요하지 않습니다.
코드베이스 분석 결과:
@nestjs/common의 내장Logger를 여러 서비스에서 사용 중입니다- 별도의 로깅 라이브러리(winston, pino 등)는 사용하지 않고 있습니다
LoggerModule과LoggerDecoratorRegister는 NestJS의 내장 Logger를 기반으로 구현되어 있습니다
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: 로거 모듈의 의존성 확인
# libs/logger 디렉토리의 import 문 검사
rg -t ts "import.*from ['\"](?!@).*logger.*['\"]" ./libs/logger
# package.json이 있는지 확인
fd -t f "package.json" ./libs/logger
Length of output: 363
Script:
#!/bin/bash
# 로거 관련 파일 검색 및 분석
echo "=== 로거 관련 파일 검색 ==="
fd -t f -e ts "logger" .
echo -e "\n=== 로거 구현 코드 분석 ==="
rg -t ts "class.*Logger" -A 5
echo -e "\n=== NestJS Logger 사용 확인 ==="
rg -t ts "Logger[,\s]" -A 2
echo -e "\n=== winston 또는 다른 로깅 라이브러리 사용 확인 ==="
rg -t ts "import.*winston"
rg -t ts "import.*pino"
Length of output: 3277
src/user/user.repository.ts (1)
14-14: @loggable 데코레이터 구현 확인 필요
Ziggle 애플리케이션의 로거를 통합하는 과정에서 @Loggable 데코레이터의 구현이 적절한지 확인이 필요합니다.
다음 스크립트를 실행하여 데코레이터 구현을 확인합니다:
✅ Verification successful
Let me gather more information about the Loggable decorator implementation.
Let me check the logger module and decorator implementation more thoroughly.
@loggable 데코레이터 구현이 적절하게 완료되었습니다
@Loggable 데코레이터는 다음과 같이 올바르게 구현되어 있습니다:
- NestJS의 메타데이터 시스템을 활용하여 구현됨
LoggerDecoratorRegister가 자동으로 메서드 실행 시간을 로깅- 비동기 메서드도 적절하게 처리
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the @Loggable decorator implementation
# Check the decorator implementation
ast-grep --pattern $'export class LoggerService {
$$$
}'
# Check how the decorator is used in other files
rg -l "@Loggable"
Length of output: 271
Script:
#!/bin/bash
# Search for Loggable decorator definition
ast-grep --pattern $'export const Loggable = $$$'
# Search for Loggable decorator class if it exists
ast-grep --pattern $'export class Loggable $$$'
# Search for any logging related files
fd -t f -e ts logger
fd -t f -e ts logging
# Check the content of any decorator files
rg -A 5 "export.*Loggable"
Length of output: 449
Script:
#!/bin/bash
# Check the logger module implementation
cat libs/logger/src/logger.module.ts
# Check the logger decorator register
cat libs/logger/src/logger.decorator.register.ts
# Check the loggable decorator implementation
cat libs/logger/src/decorator/loggable.ts
# Search for LOGGABLE constant
rg "LOGGABLE" -A 3
Length of output: 3086
src/oauth/oauth.repository.ts (1)
12-12: 로깅 데코레이터 구현이 적절합니다.
NestJS의 관점 지향 프로그래밍(AOP) 패턴을 잘 활용하여 로깅 기능을 구현했습니다.
Also applies to: 17-17
src/client/client.service.ts (1)
15-15: 로거 라이브러리 구현 확인 필요
로컬 라이브러리에서 Loggable 데코레이터를 가져오고 있습니다. 라이브러리의 구현 상태를 확인해야 합니다.
✅ Verification successful
@Loggable 데코레이터가 올바르게 구현되어 있고 프로젝트 전반에 걸쳐 일관되게 사용되고 있습니다
libs/logger라이브러리에 데코레이터가 적절히 구현되어 있습니다- 여러 서비스와 리포지토리에서 동일한 패턴으로 사용되고 있습니다
Logger인스턴스와 함께 일관되게 사용되어 로깅 표준화가 잘 이루어져 있습니다
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: 로거 라이브러리 구현 확인
# 로거 라이브러리 파일 존재 여부 확인
fd -t f "loggable.ts" "libs/logger"
# 데코레이터 구현 내용 확인
rg -A 10 "export.*Loggable" "libs/logger"
Length of output: 210
Script:
#!/bin/bash
# Description: 로거 라이브러리 구현 상세 확인
# LOGGABLE 상수 정의 확인
rg "LOGGABLE.*=" "libs/logger"
# 로거 데코레이터 사용 예제 확인
rg "@Loggable" -A 2
# 로거 관련 메타데이터 처리 확인
ast-grep --pattern 'export const LOGGABLE = $_'
Length of output: 1594
src/user/user.service.ts (2)
29-29: 🛠️ Refactor suggestion
기존 로거 인스턴스와 새로운 로깅 방식의 중복
@Loggable() 데코레이터를 도입했음에도 private readonly logger를 유지하고 있습니다. 이는 로깅 책임이 중복될 수 있습니다.
다음과 같이 변경하는 것을 추천드립니다:
- private readonly logger = new Logger(UserService.name);⛔ Skipped due to learnings
Learnt from: siwonpada
PR: gsainfoteam/idp-be#38
File: src/user/user.service.ts:23-23
Timestamp: 2024-11-19T11:25:21.180Z
Learning: `UserService` 클래스에서는 오류 핸들링을 위해 수동 로거(`private readonly logger = new Logger(UserService.name)`)와 `@Loggable()` 데코레이터를 모두 사용해야 한다.
23-23: Loggable 데코레이터 적용 검증 필요
클래스 레벨에서 @Loggable() 데코레이터를 적용한 것은 좋은 접근이지만, 이 변경으로 인한 영향을 확인해야 합니다.
Also applies to: 26-26
✅ Verification successful
Let me generate additional verification to check the Loggable decorator implementation:
Let me check one more thing to verify the decorator's impact:
@loggable 데코레이터 적용이 적절합니다
@Loggable 데코레이터는 NestJS의 메타데이터 기능을 활용한 간단한 마커 데코레이터이며, 기존 로깅 구현과 충돌하지 않습니다. 현재 서비스에서 사용 중인 private readonly logger 패턴과 함께 사용하는 것이 적절합니다.
- 다른 서비스들(
OauthService,IdpService등)에서도 동일한 패턴으로 사용되고 있습니다 - 기존 로깅 구현을 유지하면서 데코레이터를 통한 추가 기능 확장이 가능합니다
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Loggable 데코레이터의 구현 및 사용 패턴 확인
ast-grep --pattern 'class $_ {
private readonly logger = new Logger($_);
$$$
}'
# 다른 서비스에서의 Loggable 사용 패턴 확인
rg "@Loggable\(\)" -A 2
Length of output: 80676
Script:
#!/bin/bash
# Check Loggable decorator implementation
ast-grep --pattern 'export function Loggable() {
$$$
}'
# Check if there are any direct Logger usages in user.service.ts
rg "this\.logger\." src/user/user.service.ts
Length of output: 599
Script:
#!/bin/bash
# Check the lib/logger/decorator implementation
fd loggable.ts -t f -x cat {}
# Check if there are any other files using similar logging patterns
rg "private readonly logger = new Logger\(" --type ts
Length of output: 1129
src/oauth/oauth.service.ts (1)
29-29: 로깅 구현 검증 필요
@Loggable() 데코레이터를 통한 중앙화된 로깅 구현이 적절해 보입니다. 하지만 중요한 OAuth 작업들의 로깅이 올바르게 이루어지는지 확인이 필요합니다.
Also applies to: 32-32
✅ Verification successful
로깅 구현이 적절히 완료되었습니다
@Loggable() 데코레이터를 통한 로깅 구현이 다음과 같이 확인되었습니다:
- 모든 메소드 호출 전/후 자동 로깅
- 메소드 실행 시간 측정 및 기록
- 비동기 작업에 대한 적절한 처리
OAuth 서비스의 중요 작업들이 자동으로 로깅되므로 기존 수동 로깅 제거는 적절한 변경입니다.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify logging implementation in the logger module
# Check logger implementation
ast-grep --pattern 'class LoggerDecoratorRegister {
$$$
register($_, $_) {
$$$
}
$$$
}'
# Check if critical OAuth operations are covered
rg -l "LogLevel.(INFO|ERROR|WARN)" "libs/logger/src/"
Length of output: 155
Script:
#!/bin/bash
# Check for Loggable decorator implementation
ast-grep --pattern 'export function Loggable() {
$$$
}'
# Check for logger service implementation
ast-grep --pattern 'export class LoggerService {
$$$
}'
# Find all log level imports and usage
rg "LogLevel\." -A 2
# Check OAuth service implementation with logging
fd oauth.service.ts --exec cat {}
Length of output: 14623
Script:
#!/bin/bash
# Check Loggable decorator implementation details
fd loggable.ts --exec cat {}
# Check for any existing logging patterns in the codebase
rg "Logger\." -A 2 src/oauth/
# Check for any logging configurations
fd logger.module.ts --exec cat {}
Length of output: 525
Script:
#!/bin/bash
# Check logger decorator register implementation
fd logger.decorator.register.ts --exec cat {}
# Check for any logging interceptors
fd "*.interceptor.ts" --exec grep -l "Logger" {} | xargs cat
# Check for any logging middleware
rg -l "Logger" --type ts | grep middleware | xargs cat
Length of output: 2173
Fixes #37
Summary by CodeRabbit
New Features
Loggable데코레이터를 도입하여 다양한 서비스 및 리포지토리의 로깅 기능을 향상시켰습니다.LoggerModule을 추가하여 애플리케이션에 로깅 기능을 통합했습니다.cSpell.words배열에 "loggable" 단어를 추가하여 맞춤법 검사 기능을 개선했습니다.Bug Fixes
Documentation
package.json및jest-e2e.json파일의 설정을 업데이트하여 테스트 및 형식화 프로세스를 개선했습니다.