Skip to content

chore: remove dead eslint-disable comments from example files#179

Open
gabrypavanello wants to merge 1 commit intomainfrom
kaizen/2026-02-23
Open

chore: remove dead eslint-disable comments from example files#179
gabrypavanello wants to merge 1 commit intomainfrom
kaizen/2026-02-23

Conversation

@gabrypavanello
Copy link
Contributor

Kaizen — Monday Feb 23 2026

What: Removed 3 // eslint-disable-line no-console comments from examples/weather-app/ handler and middleware files.

Why: The weather-app example project has no lint target in NX — these suppressions were never evaluated by any lint run. They were dead code adding noise to files developers use as reference.

Console output is intentional in demo/example code. Even if lint were added in future, an eslint config-level override would be the right approach — not per-line suppressions.

Risk: None — comment-only change, no logic affected.

Verified: Build ✅ | Tests ✅ (1669 passed)

The weather-app example project has no lint target in NX, so the
inline `eslint-disable-line no-console` comments in handlers and
middleware were never evaluated and served no purpose. Console output
is intentional in example code anyway.

Removes 3 unnecessary suppression comments.
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 23, 2026

No actionable comments were generated in the recent review. 🎉


📝 Walkthrough

Summary by CodeRabbit

  • Chores
    • Removed unnecessary linting suppressions from example code while preserving existing logging functionality.

Walkthrough

ESLint disable comments are removed from console.log statements in two files within the weather-app example. The actual logging functionality remains unchanged; only inline linting suppressions are eliminated.

Changes

Cohort / File(s) Summary
Console Logging Lint Suppressions
examples/weather-app/handlers/app-lifecycle.ts, examples/weather-app/middleware/logging.ts
Removed eslint-disable-line comments from console.log statements, allowing logs to be subject to ESLint rules without inline suppression.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and accurately summarizes the main change: removing eslint-disable comments from example files.
Description check ✅ Passed The description is directly related to the changeset, providing clear context, rationale, and verification details about removing the eslint-disable comments.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch kaizen/2026-02-23

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.


Comment @coderabbitai help to get the list of available commands and usage tips.

@claude
Copy link
Contributor

claude bot commented Feb 23, 2026

Code Review

Summary: Removing 3 dead // eslint-disable-line no-console inline suppressions from examples/weather-app/.


Correctness of the claim

The reasoning holds up. The root eslint.config.js defines files patterns only for packages/** paths — examples/ is entirely absent. These suppressions were never evaluated by any lint run, so they are genuinely dead code.

Code quality

The change is clean and focused. Removing misleading suppressions improves the signal-to-noise ratio in reference code that developers read to learn patterns.

One suggestion worth considering

Since examples/ is currently outside the lint scope, the console.log calls are fine today. However, if someone later adds linting to the weather-app (e.g. adds a lint script to package.json), those calls would immediately produce no-console warnings because the base rule is "warn" and there is no override for example code.

A small proactive addition to eslint.config.js would make that intent explicit and prevent future churn:

// Examples — console output is intentional in demo code
{
  files: ["examples/**/*.ts", "examples/**/*.tsx"],
  rules: {
    "no-console": "off",
  },
},

This is not a blocker — the PR description already calls this out as the right approach — but landing it alongside the cleanup would close the loop completely.

Risk

None. Comment-only change; no logic affected.

Verdict

Approved as-is. The optional ESLint override above is worth a follow-up if the team ever adds linting to examples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant