☁️ Nx Cloud Report

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

📂 See all runs for this branch

Sent with 💌 from NxCloud.

Thanks for the PR, @Josh-Cena!

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. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day.

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	d39e589
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/62430019034a0700088b8439
😎 Deploy Preview	https://deploy-preview-4603--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

Not sure if any code should be updated to cope with this option. Seems our scope analyzer is already able to allow this:

type test = (test: string) => typeof test;

Even when ignoreFunctionTypeParameterNameValueShadow is turned off

Codecov Report

Merging #4603 (d39e589) into main (9707daa) will increase coverage by 2.22%.
The diff coverage is 85.36%.

@@            Coverage Diff             @@
##             main    #4603      +/-   ##
==========================================
+ Coverage   92.06%   94.28%   +2.22%     
==========================================
  Files         355      151     -204     
  Lines       12097     8208    -3889     
  Branches     3455     2670     -785     
==========================================
- Hits        11137     7739    -3398     
+ Misses        630      261     -369     
+ Partials      330      208     -122     

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

Hmmm... No! This rule does not pipe to the base rule but is a re-implementation. We do need to backport the upstream changes and add a test. My bad for not noticing it beforehand

Any reason why this rule does not delegate to the base rule? Should I refactor that in this PR? I mean... eslint/eslint#14963 has about 100 lines to add this feature, not sure if we want to duplicate all of that

Any reason why this rule does not delegate to the base rule?

At the end of the AST the base rule iterates over every single scope and variable using the scope analysis APIs and then individually reports on variables that match its internal logic.

We unfortunately can't pick-and-choose which variables the base rule might report on unless we hackily override the scope analysis APIs - which means we can't delegate! Thus we have to maintain a complete fork, sadly.

If you can figure out a clean way to refactor this to reuse the logic - feel free! I don't think that it's possible to do though.

Ugh, I see. That's unfortunate. I'll incorporate upstream changes later today.

The unit tests seem to indicate that our extension rule is reporting more errors than the base rule on the same case. Is that because of test setup, or because of our scope manager having different logics?

@lopezjurip - please don't comment on issues and prs asking for progress.
The progress as seen in this PR.
The volunteer contributors will progress it forward as they find the time.
Commenting asking for updates just spams everyone with an unnecessary notification.

This guideline is explicitly mentioned in our contributing guide

Still quite clueless. If I copied the test cases from upstream, but our rule testers report 3 errors while the original test case only expects one, how could I get the data about the extra errors? How do people usually debug this?

I tried logging the variable name before context.report, but only one report is logged. I don't know where the extra errors are coming from at all.

How do people usually debug this?

you can use the vscode debugger to debug the tests - we have it configured so you just need to open the file and select the lint rule debugger.

also you can set only: true on the specific test case you're looking at so you can focus and remove noise.

I finally got time to look at this. I had to hack into eslint's rule tester so I can let it log the actual line/column of the report. Turns out that the tests on their repo would turn all source code into one line, so the line/column numbers are different from ours.