Skip to content

chore: enable no-non-null-assertion internally, excluding tests #8019

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

JoshuaKGoldberg
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg commented Dec 3, 2023

PR Checklist

Overview

Moves the disable of @typescript-eslint/no-non-null-assertion to test files. Adds a whole bunch of disables nullThrows to the remaining violations. I think we have so many because we're normally pretty good at not adding unnecessary !s, so any ! that was added was generally there for a good reason.

Also adds a unit test to the actually-testable case in nullThrows.

@typescript-eslint
Copy link
Contributor

Thanks for the PR, @JoshuaKGoldberg!

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.

Copy link

netlify bot commented Dec 3, 2023

Deploy Preview for typescript-eslint ready!

Name Link
🔨 Latest commit fb8276e
🔍 Latest deploy log https://app.netlify.com/sites/typescript-eslint/deploys/65e737b25f31760008211a1a
😎 Deploy Preview https://deploy-preview-8019--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: 89 (🔴 down 1 from production)
Accessibility: 100 (no change from production)
Best Practices: 92 (no change from production)
SEO: 98 (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 site configuration.

line,
};
});
}
Copy link
Member Author

Choose a reason for hiding this comment

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

Dead code 🔪 #8021

@JoshuaKGoldberg JoshuaKGoldberg marked this pull request as ready for review December 3, 2023 15:54
Copy link
Member

@bradzacher bradzacher left a comment

Choose a reason for hiding this comment

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

I do wonder if this rule is good for our codebase - this PR adds 114 disable comments across our packages - which is a large amount! (Plus the number in the files that have the rule completely disabled via unlimited comment).

Perhaps there's something we can do better here in regards to the types to make things less "hacky"?
Perhaps some of these should be converted to runtime checks (eg we have the nullThrows util)

@JoshuaKGoldberg
Copy link
Member Author

Yeah especially around the token stuff, agreed. Will draft & put in my queue...

@JoshuaKGoldberg JoshuaKGoldberg marked this pull request as draft December 4, 2023 16:03
@Josh-Cena
Copy link
Member

FWIW, this is one of the rules I passionately hate, and I think it just adds a lot of noise to most codebases that are not written by novices. I'm okay to have it just for dogfooding, though.

@JoshuaKGoldberg JoshuaKGoldberg marked this pull request as ready for review February 4, 2024 17:49
@JoshuaKGoldberg JoshuaKGoldberg added the blocked by another PR PRs which are ready to go but waiting on another PR label Feb 5, 2024
@JoshuaKGoldberg
Copy link
Member Author

JoshuaKGoldberg commented Feb 5, 2024

I'll wait to merge these changes until the flat config work lands.

(they haven't been approved, but just in case they are)

Edit: ✔️

@JoshuaKGoldberg JoshuaKGoldberg removed the blocked by another PR PRs which are ready to go but waiting on another PR label Feb 21, 2024
Copy link

codecov bot commented Feb 21, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.75%. Comparing base (aeb2f71) to head (6002611).

❗ Current head 6002611 differs from pull request most recent head fb8276e. Consider uploading reports for the commit fb8276e to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #8019      +/-   ##
==========================================
- Coverage   87.90%   87.75%   -0.16%     
==========================================
  Files         397      398       +1     
  Lines       13844    13828      -16     
  Branches     4074     4068       -6     
==========================================
- Hits        12170    12135      -35     
- Misses       1372     1396      +24     
+ Partials      302      297       -5     
Flag Coverage Δ
unittest 87.75% <100.00%> (-0.16%) ⬇️

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

Files Coverage Δ
...lugin-internal/src/rules/plugin-test-formatting.ts 79.19% <ø> (ø)
packages/eslint-plugin-tslint/src/rules/config.ts 100.00% <ø> (ø)
packages/eslint-plugin/src/rules/ban-ts-comment.ts 97.29% <ø> (ø)
packages/eslint-plugin/src/rules/block-spacing.ts 100.00% <ø> (ø)
packages/eslint-plugin/src/rules/brace-style.ts 95.23% <ø> (ø)
packages/eslint-plugin/src/rules/comma-spacing.ts 100.00% <ø> (ø)
...lugin/src/rules/consistent-generic-constructors.ts 90.24% <100.00%> (ø)
...int-plugin/src/rules/consistent-type-assertions.ts 92.30% <100.00%> (ø)
...eslint-plugin/src/rules/consistent-type-imports.ts 95.25% <100.00%> (ø)
...kages/eslint-plugin/src/rules/enum-utils/shared.ts 85.18% <100.00%> (ø)
... and 45 more

... and 21 files with indirect coverage changes

Comment on lines +97 to +100
return nullThrows(
context.sourceCode.getTokenAfter(node.key),
NullThrowsReasons.MissingToken(']', 'key'),
);
Copy link
Member

Choose a reason for hiding this comment

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

this pattern is so common - i wonder if we should create a utility to wrap it up and make it even shorter?

eg getRequiredTokenAfter(sourceCode, node.key, 'optional message')

Copy link
Member Author

Choose a reason for hiding this comment

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

I like it!

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, tried this out - but in order to get the same precision of logs we'd need to still pass in ']' and key as well.

return getRequiredTokenAfter(
  context.sourceCode,
  node.key,
  ']',
  'key',
);

I feel like I'd rather get this merged in now, then look at more options in a followup. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

I wonder if we should just say "fuck it" and create an API without the message.
It makes the end user experience worse cos more vague error messages - but it would be much cleaner and better devx.

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't really mind having the extra verbosity for our devx, personally. It's been forcing me to think more carefully about what we're actually asserting on.

bradzacher
bradzacher previously approved these changes Mar 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants