Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃殌 Feature: the case for @typescript-eslint/consistent-type-imports #1172

Closed
3 tasks done
johnnyreilly opened this issue Jan 1, 2024 · 2 comments
Closed
3 tasks done
Labels
status: wontfix This will not be worked on type: feature New enhancement or request

Comments

@johnnyreilly
Copy link
Sponsor Collaborator

Bug Report Checklist

  • I have tried restarting my IDE and the issue persists.
  • I have pulled the latest main branch of the repository.
  • I have searched for related issues and found none that matched my issue.

Overview

I'm not sure if I should be suggesting this here or as part of plugin:@typescript-eslint/recommended, but here seems like a good enough place to start a discussion. Objectively I know this is definitely a "John has a preference thing", but let's see where it goes.

I very much appreciate distinguishing between type import and value imports. They are different things and I believe it aids the readability of code and is therefore a GOOD THING 鈩笍

Observe my paean to @typescript-eslint/consistent-type-imports here: https://johnnyreilly.com/typescript-5-importsnotusedasvalues-error-eslint-consistent-type-imports#eslint-and-typescript-eslintconsistent-type-imports-to-the-rescue

The question is, should this be a default part of the ruleset for CTA? As this is clearly and demonstrably the most important ESLint rule of all time. (I jest, but only slightly 馃槃 )

The answer can of course be "no, you're a little over the top about this" - I realise that I am.

https://typescript-eslint.io/rules/consistent-type-imports/

Additional Info

N/A

@johnnyreilly johnnyreilly added the type: feature New enhancement or request label Jan 1, 2024
@JoshuaKGoldberg
Copy link
Owner

Hah I think you're very much right about it for your use cases. But some folks prefer keeping things all inline in projects where it doesn't make a functional difference. E.g. if the project is built with a bundler then consistent exports and imports become "just" a style concern. Specifically:

I believe it aids the readability of code and is therefore a GOOD THING 鈩笍

I believe it makes it can make code harder to read by cluttering it with type keywords. 馃槣

Closing as wontfix because it's just a bit more opinionated than what this template goes for. If you set it enabled in all your projects then that's totally reasonable.

I also imagine if there's opportunity for feature work in making it easier for folks to add "overrides" on top of this template's tooling? This would be a good use case. Another might be adding in framework-specific lint rules such as React's. That'd be tracked by the work in making a generalized engine: #498 (comment)

@JoshuaKGoldberg JoshuaKGoldberg closed this as not planned Won't fix, can't repro, duplicate, stale Jan 2, 2024
@JoshuaKGoldberg JoshuaKGoldberg added the status: wontfix This will not be worked on label Jan 2, 2024
@johnnyreilly
Copy link
Sponsor Collaborator Author

johnnyreilly commented Jan 2, 2024

I believe it makes it can make code harder to read by cluttering it with type keywords. 馃槣

Josh, I want you to know that I respect your right to be wrong 馃槈

@andrewbranch - terrible news... 馃槃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: wontfix This will not be worked on type: feature New enhancement or request
Projects
None yet
Development

No branches or pull requests

2 participants