-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
chore: enable prefer-template #9544
chore: enable prefer-template #9544
Conversation
Thanks for the PR, @abrahamguo! 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. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
`import type * as ${safeName} from '${from}';\n` + | ||
text.replace(regex, safeName) | ||
); | ||
return `import type * as ${safeName} from '${from}';\n${text.replace( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make \n
a literal character
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just a curiosity question — do you feel it's a case-by case decision on whether to use an explicit \n
vs a literal newline?
I was just curious because there are hundreds of places throughout our codebases that use explicit \n
s, so I was wondering if you were in favor of any consistent pattern, or if it just depends?
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #9544 +/- ##
==========================================
- Coverage 88.45% 88.45% -0.01%
==========================================
Files 422 422
Lines 14695 14694 -1
Branches 4298 4298
==========================================
- Hits 12998 12997 -1
Misses 1372 1372
Partials 325 325
Flags with carried forward coverage won't be shown. Click here to find out more.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving my +1
I know some of y'all have strong (and different) opinions about code, and this seems like a less straightforward one, so let's get more opinions. |
As noted in discussion, I'm not a big fan of this approach to solving the reports by this rule. I think we should reach for an aliased variable for cases with anything more than a truly trivial expression in the interpolation. However, I'll leave an approval to signal there's nothing problematically merge-blocking and that you should feel free to proceed without satisfying my stylistic preferences 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'm not super picky here 😄, let's just merge and see how it goes. Thanks!
PR Checklist
Overview
Enable
prefer-template
(docs). 100% autofixable.