Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@bradzacher
Copy link
Member

PR Checklist

Overview

This PR implements an extension rule for no-unused-private-class-members that introduces support for private members.

@bradzacher bradzacher added the enhancement: new base rule extension New base rule extension required to handle a TS specific case label Mar 3, 2025
@typescript-eslint
Copy link
Contributor

Thanks for the PR, @bradzacher!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!


🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint.

@netlify
Copy link

netlify bot commented Mar 3, 2025

Deploy Preview for typescript-eslint ready!

Name Link
🔨 Latest commit f7beddc
🔍 Latest deploy log https://app.netlify.com/projects/typescript-eslint/deploys/691362c4eb88bb0008373ad7
😎 Deploy Preview https://deploy-preview-10913--typescript-eslint.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
Lighthouse
Lighthouse
1 paths audited
Performance: 78 (🔴 down 18 from production)
Accessibility: 97 (no change from production)
Best Practices: 100 (no change from production)
SEO: 92 (no change from production)
PWA: 80 (no change from production)
View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify project configuration.

@nx-cloud
Copy link

nx-cloud bot commented Mar 3, 2025

View your CI Pipeline Execution ↗ for commit f7beddc

Command Status Duration Result
nx test eslint-plugin --coverage=false ✅ Succeeded 4m 53s View ↗
nx run-many -t lint ✅ Succeeded 3m 19s View ↗
nx run-many -t typecheck ✅ Succeeded 2m 15s View ↗
nx test eslint-plugin-internal --coverage=false ✅ Succeeded 4s View ↗
nx run integration-tests:test ✅ Succeeded 5s View ↗
nx test typescript-estree --coverage=false ✅ Succeeded 2s View ↗
nx run types:build ✅ Succeeded 5s View ↗
nx run generate-configs ✅ Succeeded 7s View ↗
Additional runs (29) ✅ Succeeded ... View ↗

☁️ Nx Cloud last updated this comment at 2025-11-11 16:33:26 UTC

@nx-cloud
Copy link

nx-cloud bot commented Mar 3, 2025

View your CI Pipeline Execution ↗ for commit 34b77b8.


☁️ Nx Cloud last updated this comment at 2025-03-03 02:18:54 UTC

JoshuaKGoldberg
JoshuaKGoldberg previously approved these changes Mar 3, 2025
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conan O'Brien frankly saying 'yep'

@JoshuaKGoldberg JoshuaKGoldberg added the 1 approval >=1 team member has approved this PR; we're now leaving it open for more reviews before we merge label Mar 3, 2025
// mark the first member we encounter as used. If you were to delete the
// member, then any subsequent usage could incorrectly mark the member of
// an encapsulating parent class as used, which is incorrect.
trackedClassMembersUsed.add(memberDefinition.declaredNode);
Copy link
Member

@ronami ronami Mar 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Bug]: I've noticed some missed reports with functions that have a different this than the class instance (deploy preview playground link):

class Test1 {
  // should be reported but doesn't?
  private bar: number;

  foo = function () {
    return this.bar;
  }
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because the base rule doesn't support that case because this.#bar is a syntax error inside a function expression!!

It's worth noting that TS doesn't actually catch this case either and reports bar as unused because the type of the this in the function expression is any!
If you turn on noImplicitThis then TS will error on that this

We could support this if we wanted to. I'm leaning towards not because TS itself doesn't catch it either.

Copy link
Member

@ronami ronami Mar 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! I think the rule should report bar as unused in this case. I've mentioned this since TypeScript reports it as unused but the rule doesn't report it as unused (regardless of the type error).

Copy link
Member Author

@bradzacher bradzacher Oct 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coming back to this -- my code handles this correctly because realistically it is an actual usage of the parameter.

For example new Test1().foo() will return the value of bar.
There's an implicit binding here and so I think this is fine to keep not reporting on.

Copy link
Member

@ronami ronami left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks amazing! Excited to enable this on projects I work on 🚀🚀🚀

(I accidentally posted the review earlier while still adding comments 🙈)

@bradzacher
Copy link
Member Author

FYI I'm going to make @Josh-Cena very happy - I'm going to build a "class scope analyser" so we can do this right rather than just hacking it in.

This does mean that I'm going to rewrite the rule from the ground up -- but it'll be worht it

@kirkwaiblinger
Copy link
Member

kirkwaiblinger commented Mar 19, 2025

FYI I'm going to make @Josh-Cena very happy - I'm going to build a "class scope analyser" so we can do this right rather than just hacking it in.

This does mean that I'm going to rewrite the rule from the ground up -- but it'll be worht it

Do you intend for this to proceed as-is, with this work intended to happen in the future, or should we pause/draft it pending this work?

@bradzacher
Copy link
Member Author

Let's draft it.
We need to at least handle the static property case.
Might have some time soon to pick the work back up.

@kirkwaiblinger kirkwaiblinger added the awaiting response Issues waiting for a reply from the OP or another party label Mar 19, 2025
@kirkwaiblinger kirkwaiblinger marked this pull request as draft March 19, 2025 09:39
@JoshuaKGoldberg JoshuaKGoldberg removed the 1 approval >=1 team member has approved this PR; we're now leaving it open for more reviews before we merge label Mar 24, 2025
@bradzacher bradzacher removed the awaiting response Issues waiting for a reply from the OP or another party label Jul 13, 2025
@bradzacher bradzacher marked this pull request as ready for review August 10, 2025 05:39
Copy link
Member

@ronami ronami left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks amazing and a very beneficial rule to have; just a few small comments from me 🚀🚀🚀

meta: {
type: 'problem',
docs: {
description: 'Disallow unused private class members',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a bug and shouldn't be reported (deploy preview playground link):

class Test1 {
  // reported but shouldn't?
  private foo: number | null;

  public bar() {
    this.foo ??= 1;
  }
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a weird case that isn't currently reported by no-unused-vars but really should be.

It is reported by the base no-unused-private-class-members rule

Copy link
Member

@kirkwaiblinger kirkwaiblinger Aug 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was just a recent eslint bug report about these; I guess it's intentional for no-unused-vars since x ?? = y reads x first (equivalent to x != null ? x : (x = y)) rather than unconditionally assigning (x = x != null ? x : y). See eslint/eslint#20029. But presumably the two rules should agree?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, but do note that these are reported by no-useless-assignment so 🤷‍♂️ 🤷‍♂️

(playground)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should probably file a bug for NUPCM then so it matches NUV?

@JoshuaKGoldberg JoshuaKGoldberg added the awaiting response Issues waiting for a reply from the OP or another party label Sep 29, 2025
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have very little to add that Kirk and Ronami didn't already. Very exciting!! ⚡

*/
export function extractNameForMember(node: MemberNode): [Key, string] | null {
if (node.computed) {
return extractComputedName(node.key);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noting, #11006 has some other logic around computed keys. It might be useful to unify?

@bradzacher
Copy link
Member Author

@ronami / @JoshuaKGoldberg / @kirkwaiblinger

Added support for:

Parameter properties

class Test1 {
  constructor(
    // errors
    private parameterPropertyUnused: number,
    // no error
    private parameterPropertyUsed: number,   
  ) {}

  method() {
    return this.parameterPropertyUsed;
  }
}

Usage of a private class member via explicitly and simply annotated variables:

class Foo {
  // no longer reported
  private prop: number;
  // no longer reported
  private staticProp: number;

  method1(thing: Foo) {
    return thing.prop;
  }
  method2(thing: typeof Foo) {
    return thing.staticProp;
  }
}

Usage of a private class member via simple assignment:

class Foo {
  // no longer reported
  private prop: number;
  method() {
    const self = this;
    return self.prop;
  }
}

@bradzacher bradzacher removed the awaiting response Issues waiting for a reply from the OP or another party label Oct 20, 2025
JoshuaKGoldberg
JoshuaKGoldberg previously approved these changes Nov 3, 2025
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lint complaints notwithstanding, this looks great to me! I'll defer to the other reviewers on the finer points they're calling out. But the overall scope analyzer looks great and I'm very happy with the clean rule implementation. Nicely done! 👏

@JoshuaKGoldberg JoshuaKGoldberg added the 1 approval >=1 team member has approved this PR; we're now leaving it open for more reviews before we merge label Nov 3, 2025
ronami
ronami previously approved these changes Nov 5, 2025
Copy link
Member

@ronami ronami left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking great 👏👏👏

@bradzacher bradzacher dismissed stale reviews from ronami and JoshuaKGoldberg via 2ccb638 November 11, 2025 16:21
@bradzacher bradzacher force-pushed the no-unused-private-class-members branch from 408410c to 2ccb638 Compare November 11, 2025 16:21
@codecov
Copy link

codecov bot commented Nov 11, 2025

Codecov Report

❌ Patch coverage is 82.10181% with 109 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.56%. Comparing base (0fac889) to head (f7beddc).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
...rc/util/class-scope-analyzer/classScopeAnalyzer.ts 82.45% 82 Missing and 1 partial ⚠️
...c/util/class-scope-analyzer/extractComputedName.ts 65.33% 26 Missing ⚠️

❌ Your patch status has failed because the patch coverage (82.10%) is below the target coverage (90.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #10913      +/-   ##
==========================================
- Coverage   90.66%   90.56%   -0.10%     
==========================================
  Files         518      522       +4     
  Lines       52454    53063     +609     
  Branches     8694     8838     +144     
==========================================
+ Hits        47558    48058     +500     
- Misses       4882     4990     +108     
- Partials       14       15       +1     
Flag Coverage Δ
unittest 90.56% <82.10%> (-0.10%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
packages/eslint-plugin/src/configs/eslintrc/all.ts 100.00% <100.00%> (ø)
packages/eslint-plugin/src/configs/flat/all.ts 100.00% <100.00%> (ø)
...lugin/src/rules/no-unused-private-class-members.ts 100.00% <100.00%> (ø)
...lint-plugin/src/util/class-scope-analyzer/types.ts 100.00% <100.00%> (ø)
...c/util/class-scope-analyzer/extractComputedName.ts 65.33% <65.33%> (ø)
...rc/util/class-scope-analyzer/classScopeAnalyzer.ts 82.45% <82.45%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@bradzacher bradzacher merged commit 6c6db24 into main Nov 11, 2025
66 of 69 checks passed
@bradzacher bradzacher deleted the no-unused-private-class-members branch November 11, 2025 16:34
@bradzacher bradzacher linked an issue Nov 11, 2025 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

1 approval >=1 team member has approved this PR; we're now leaving it open for more reviews before we merge enhancement: new base rule extension New base rule extension required to handle a TS specific case

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Rule proposal: no-unused-private-class-members

5 participants