Skip to content

feat(eslint-plugin): new rule prefer-signals #1872

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

reduckted
Copy link
Contributor

@reduckted reduckted commented Jun 8, 2024

Fixes #1719 and #1824.

This rule checks a few things.

Prefer Signals

This rule will report a problem when a BehaviorSubject is created. This type name can be overridden in the options. That allows this part of the rule to be skipped (by specifying an empty array), or to include additional types that should be replaced with signals.

There is no suggestion for this part of the rule.

Prefer Readonly

This rule will report a problem for any class property that does not have the readonly modifier and either:

  • Has a type annotation of:
    • Signal
    • InputSignal
    • ModelSignal
    • WritableSignal
  • Is assigned the result of:
    • computed()
    • contentChild()
    • contentChild.required()
    • contentChildren()
    • input()
    • input.required()
    • model()
    • signal()
    • viewChild()
    • viewChild.requried()
    • viewChildren()
  • If type checking is enabled, the type is computed to be a type of signal (the same type names that the type annotation is checked for).

This part of the rule can be disabled.

Prefer Input Signals

This rule will report a problem when @Input is used. This part of the rule can be disabled.

Prefer Query Signals

This rule will report a problem when @ContentChild, @ContentChildren, @ViewChild or @ViewChildren is used. This part of the rule can be disabled.

Copy link

nx-cloud bot commented Jun 8, 2024

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 566c278. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution


✅ Successfully ran 7 targets

Sent with 💌 from NxCloud.

Copy link

codecov bot commented Jun 8, 2024

Codecov Report

Attention: Patch coverage is 94.82759% with 3 lines in your changes missing coverage. Please review.

Project coverage is 91.05%. Comparing base (ba27de5) to head (566c278).
Report is 18 commits behind head on next-major-release/v19.

Files with missing lines Patch % Lines
packages/eslint-plugin/src/rules/prefer-signals.ts 93.75% 2 Missing and 1 partial ⚠️
Additional details and impacted files
@@                    Coverage Diff                     @@
##           next-major-release/v19    #1872      +/-   ##
==========================================================
+ Coverage                   90.99%   91.05%   +0.06%     
==========================================================
  Files                         181      183       +2     
  Lines                        3475     3533      +58     
  Branches                      580      595      +15     
==========================================================
+ Hits                         3162     3217      +55     
- Misses                        165      167       +2     
- Partials                      148      149       +1     
Flag Coverage Δ
unittest 91.05% <94.82%> (+0.06%) ⬆️

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

Files with missing lines Coverage Δ
.../eslint-plugin/tests/rules/prefer-signals/cases.ts 100.00% <100.00%> (ø)
packages/eslint-plugin/src/rules/prefer-signals.ts 93.75% <93.75%> (ø)
---- 🚨 Try these New Features:

@reduckted reduckted force-pushed the feature/prefer-signal-readonly branch from fc07c06 to 7103aeb Compare June 8, 2024 07:44
@reduckted
Copy link
Contributor Author

reduckted commented Jun 14, 2024

toSignal is another function to check for.

Edit: Done! ✔️

@JamesHenry
Copy link
Member

I'm strongly thinking we will want to have a prefer-signals rule very soon, and having prefer-signals and prefer-signal-readonly is maybe a little clunky...

It feels like readonly is pretty objectively desirable for these APIs, so maybe we make it so that prefer-signals also enforces readonly by default, but that rule has an option to disable it if people strongly dislike it for some reason? 🤔

I do agree with @MillerSvt that we need to at least have the option to use type information for enforcing signals usage.

@reduckted would you like to collaborate on the prefer-signals implementation?

@reduckted
Copy link
Contributor Author

Makes sense to just have a single prefer-signals rule with a bunch of options, so I'm happy for this to not be merged.

I'd be happy to help out with that rule. Is #1824 the existing issue about it?

In the meantime, I'll switch this PR to draft and update it to include type checking just so we have the implementation available somewhere.

@reduckted reduckted marked this pull request as draft July 8, 2024 02:22
@reduckted
Copy link
Contributor Author

I've added two options:

  • useTypeChecking: When true, type-checking will be used as a last resort.
  • signalCreationFunctions: An array of user-defined function names that create signals. This allows those custom functions to be declared and treated like the built-in functions (signal, model, etc.) while also avoiding type-checking.

@reduckted reduckted changed the title feat(eslint-plugin): new rule prefer-signal-readonly feat(eslint-plugin): new rule prefer-signals Jul 10, 2024
@reduckted
Copy link
Contributor Author

I've changed this rule to prefer-signals and added a few more options. I've updated my initial comment with everything that the rule now does.

Feel free to critique anything that doesn't seem right, or isn't implemented in the preferred style. 😁

@pumano
Copy link
Contributor

pumano commented Jul 10, 2024

Would love to use it, when it merged.

@reduckted reduckted marked this pull request as ready for review July 24, 2024 10:05
@reduckted reduckted requested a review from JamesHenry August 16, 2024 12:52
Copy link

@JanProchy JanProchy 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!

@Mr-Jami
Copy link

Mr-Jami commented Oct 7, 2024

Exactly what I am looking for. Looking forward to try it out when merged.

@pumano
Copy link
Contributor

pumano commented Oct 16, 2024

any news on this?

@NateRadebaugh
Copy link

@JamesHenry is this something on your radar to review and complete soon? I think @reduckted addressed your concerns at this point

@JamesHenry JamesHenry mentioned this pull request Nov 21, 2024
14 tasks
@JamesHenry JamesHenry changed the base branch from main to next-major-release/v19 November 23, 2024 10:34
@JamesHenry
Copy link
Member

I'm going to merge this into #2109 and apply some tweaks, many thanks again!

@JamesHenry JamesHenry merged commit db6e02b into angular-eslint:next-major-release/v19 Nov 23, 2024
8 checks passed
@reduckted reduckted deleted the feature/prefer-signal-readonly branch November 23, 2024 10:36
JamesHenry pushed a commit that referenced this pull request Nov 23, 2024
Co-authored-by: Dave <reduckted@outlook.com>
@JamesHenry
Copy link
Member

@reduckted I wasn't fully happy with the scope of the arbitrary typesToReplace and the implementation only considered things being instantiated with new which made sense for BehaviorSubject, but not the arbitrary user provided list. I have therefore removed that for the initial version, as well as tweaked some messages and options, but thank you again for tackling the lion's share of this

@JamesHenry
Copy link
Member

We can revisit preferring signals over arbitrary things in a dedicated follow up

JamesHenry pushed a commit that referenced this pull request Nov 23, 2024
Co-authored-by: Dave <reduckted@outlook.com>
JamesHenry pushed a commit that referenced this pull request Nov 29, 2024
Co-authored-by: Dave <reduckted@outlook.com>
JamesHenry pushed a commit that referenced this pull request Nov 29, 2024
Co-authored-by: Dave <reduckted@outlook.com>
@Frotty
Copy link

Frotty commented Dec 4, 2024

Great addition, but the rule cannot be used, see #2149

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.

[prefer-readonly-signals] New rule for checking that signals are defined as readonly
9 participants