-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
chore: use named import for util
#7669
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: use named import for util
#7669
Conversation
Thanks for the PR, @antfu! 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. |
util
util
util
util
util
util
3fd5bdd
to
41d8b51
Compare
The failing tests seem to be inherited from the main bench. |
We never use dynamic lookups, so shouldn't bundlers be able to tree shake them? This feels like an issue with bundlers not supporting a very reasonable style IMO. |
Well, to my surprise, rollup does tree-shake well (but I guess you need to be careful not reference the object entirely, it's not a concern with the current codebase). Then, I think the issue would fall into mainly consistency/preferences. In that case, I don't have strong opinions over which. |
I prefer named imports. The name |
@typescript-eslint/triage-team I'm up for merging this as-is (so, moving to named imports), for consistency's sake and because tree shaking can be complex sometimes even when everything is configured well. Any objections? |
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.
Approving knowing that we might have to clean some stuff up after merging from main
.
Thanks @antfu! |
type, | ||
ts.TypeFlags.Undefined, | ||
); | ||
const typeIncludesNull = util.isTypeFlagSet( | ||
const typeIncludesNull = tsutils.isTypeFlagSet( |
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.
Aha! A behavior change. Might be from a merge. I'll fix.
Confusingly, the two isTypeFlagSet
functions aren't the same.
d683758
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.
I got through one util.isTypeFlagSet
-> tsutils.isTypeFlagSet
swap, but it looks like there are still a few more. Requesting changes on fixing that up please. Once yarn lint
passes I think we'll be good to go!
Should be good now :) |
Thanks! |
PR Checklist
(sorry for sending this PR without an issue, as I consider it a straightforward refactor)
Overview
Currently, we are mixing the usage for
* as util
and named import in different rules (and even both in the same file).I think named import is a generally better syntax as it enables tree-shaking, improves overall consistency, and would help https://github.com/eslint-stylistic/eslint-stylistic to migrate away those formatting rules (we want tree-shaking to avoid bundling all utils again).