Add a lint rule and CI check for unbounded `console`/debug output leaking into production builds
@shobhamerabacha-star is already working on this.
Since Oct 9, 2026.
Assessment
- Difficulty
- 3/5
- Estimated time
- Half a day
- Newbie friendliness
- 55/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- eslint, github-actions, nodejs, typescript
Research direction
Start with .eslintrc.js to add the no-console and no-floating-promises rules, then with .github/workflows/build-check.yml for the grep step, and package.json line 18 for the lint script that uses --fix. The six console.* calls are in src/, including src/common/database/database-index.service.ts:117, and the floating promise is at src/profiling/profiling.service.ts:144. Done means the rules are configured with spec files excluded, the calls use the configured logger, the CI grep fails on reintroduced console.*, and npm test and npx tsc --noEmit pass. The warn-or-error choice and logger choice are not settled in the issue, so confirm them first.
Written by the indexing model from the issue text.
Description
Problem
Six raw console.* calls remain in src/, including one in src/common/database/database-index.service.ts:117. .eslintrc.js has no no-console rule, and CI (.github/workflows/build-check.yml) runs tsc --noEmit, a narrow Jest subset, and the build — none of which flags this.
There is a related smell: src/profiling/profiling.service.ts:144 uses setTimeout(async () => { ... }), wrapping an async callback in a timer with no error handling — a floating promise that would produce an unhandled rejection rather than a visible failure.
Why it matters
In an operator-facing system, unhandled output and unhandled rejections both hide real failures. A console.log that nobody routes goes to stdout with no request context (see the logging-facade issue), and an async callback inside setTimeout whose promise rejects is silent by default in Node.
The general lesson: the lint config does not currently guard several classes of mistake that matter here, and CI does not compensate.
Suggested Direction
- Add
no-consoleto.eslintrc.jsas a warning, withwarn/errorallowed only if the team wants to keep those:
Move the six existing calls to the configured logger in the same PR.'no-console': ['warn', { allow: ['warn', 'error'] }], - Add
no-async-promise-executorand a floating-promise guard. TypeScript'sno-floating-promisesneeds type-aware linting;parserOptions.projectis already configured in.eslintrc.js, so the type-aware rules are available. Enable@typescript-eslint/no-floating-promisesas a warning — it would have caughtprofiling.service.ts:144. - Exclude spec files from
no-console, since asserting on console output is legitimate in tests. - Add a CI grep as a hard backstop, since lint runs with
--fix(package.json:18) and may rewrite rather than fail:- name: Reject console.* in src run: | if grep -rn --include='*.ts' -E 'console\.(log|debug)' src/ ; then echo 'console.* found in src/ - use the configured logger' exit 1 fi - Treat
npm run lintcarefully. It runs with--fix, which rewrites files rather than failing. A separatelint:checkwithout--fixwould be a better CI gate.
Constraints
- Spec files legitimately use
console; scope the rule and the grep to exclude*.spec.ts. - Generated files (
src/graphql/client/generated.ts) should be excluded from any of this. - Do not introduce a different formatter/linter in this issue — the config and dependency-alignment issues cover that.
Acceptance Criteria
-
no-consoleis configured in.eslintrc.js, scoped to exclude spec files. - The six existing
console.*calls insrc/are replaced with the configured logger. -
profiling.service.ts:144is fixed and covered byno-floating-promises. - A CI step fails if
console.*reappears insrc/. -
npm testandnpx tsc --noEmitpass.
- Dominant language
- TypeScript
- Stars
- 7
- Forks
- 55
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 5
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SourceXXL/alian_structure-api
-
good first issue help wanted security
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SourceXXL/alian_structure-api#266 ·
-
Parallelize the cache-warming loop in `cache-warming.service.ts` — warmers run strictly sequentiallyPossibly taken @syntaxsuuvam-spec claimed this 2 days ago. Opengood first issue performance
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SourceXXL/alian_structure-api#240 ·
-
documentation help wanted intermediate refactor
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
SourceXXL/alian_structure-api#215 ·
-
good first issue refactor tooling
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
SourceXXL/alian_structure-api#199 ·
-
help wanted intermediate refactor
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
SourceXXL/alian_structure-api#196 ·
All issues in SourceXXL/alian_structure-api
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 83/100
Zettlr/Zettlr#6610 · 1 comment ·
Maintainers usually reply within 1 day
-
Feil lovtekst i bekreftelsen når leder melder unntak fra oppfølgingsplanPossibly taken @AudunSorheim claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 92/100
navikt/syfo-oppfolgingsplan-frontend#1110 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
db-ux-design-system/core-web#8461 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Cannot run an integration on windows when power shell is selected as the default profile terminalOpenPriority/Blocker Type/Bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
wso2/product-integrator#2767 ·
Maintainers usually reply within 1 day