Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Remove the 6 remaining `console.*` calls from `src/` in favour of the configured logger

Open
  • Is something wrong?
#206 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
70/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Active
Tech stack
nodejs, typescript
Domain
backend, observability

Research direction

Grep src/**/*.ts for console.log, debug, warn and error, then check each hit. Compare with src/rate-limiting/rate-limiter.service.ts and src/file-upload.controller.ts:47 to see the Logger pattern, and keep each original log level. Check each site for secrets before converting. Done when no console calls remain in src outside spec files, .eslintrc.js has the no-console rule, and npm run lint and npm test pass.

Written by the indexing model from the issue text.

Description

good first issue refactor

Problem

Six console.* calls remain in production source. The project has a full logging stack already — winston, pino, winston-daily-rotate-file, winston-cloudwatch in package.json, a dedicated src/logging/ module (14 files), and a custom GlobalExceptionFilter registered at src/app.module.ts:302-305.

Grep src/**/*.ts for console\.(log|debug|warn|error) and inspect each hit.

Why it matters

Direct console output bypasses every configured concern: it is not structured, not level-filtered, not routed to the rotating file or CloudWatch, and not tagged with the request or trace context that the OTel instrumentation attaches. In a production incident you would be grepping raw stdout while the rest of the system writes structured JSON.

The README's "Observable & auditable" design principle (line 32) and docs/monitoring.md both assume structured logging; these six calls are the exceptions.

Suggested Direction

  1. Locate all six sites.
  2. For Nest classes, use the built-in private readonly logger = new Logger(ClassName.name) — this pattern is already used throughout src/ (for example file-upload.controller.ts:47). Call this.logger.error(...) / warn(...) / log(...) with an object payload rather than string interpolation.
  3. For services already using winston, replace with their injected logger rather than adding a second one.
  4. Guard against a real regression this exposes: src/rate-limiting/rate-limiter.service.ts and the profiling services already use structured loggers. Match them.
  5. Add no-console to .eslintrc.js to prevent regressions: 
    'no-console': ['warn', { allow: ['warn', 'error'] }],

Note src/monitoring/monitoring-dashboard.spec.ts:32 matched a similar grep — confirm spec files are excluded or handled separately, since asserting on console output is legitimate in tests.

Constraints

  • Log levels carry meaning here: do not convert an error into a log to make output quieter.
  • Never log secrets, tokens, or wallet private keys — check each site for that before converting.
  • lint currently runs with --fix in package.json:18, so be aware the lint command will rewrite files.

Acceptance Criteria

  • No console.* calls remain in src/ outside spec files.
  • Each replacement preserves the original log level.
  • no-console is configured in .eslintrc.js.
  • No credentials or tokens are passed to any logger.
  • npm run lint and npm test pass.
Dominant language
TypeScript
Stars
7
Forks
55
Avg merge
1d 17h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SourceXXL/alian_structure-api

All issues in SourceXXL/alian_structure-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.