Blog post: 'If I wrote a linter' #284
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Super raw notes...
Downgrade visual severity to warning by default in the editor extension
Pluggable type system API alongside parser
Background daemon for project type information
Lintbase equivalent
Community outreach for major breakages and new versions - sourced by lintbase
Current version of ajv schema or a maintained equivalent, maybe ... zod?
AST selectors can only be the nodes. Easier the system and internal complexity
Proactive wotk with community linters
Proactive perception and PR work
Community discord and office hours
no stalebots
Allowlist of folder overrides in the root-level config
zod schema for rule options
There was a problem hiding this comment.
define config has dedicated property for ignores
granular report configuration: switch suggestion(s) to fix
standardized options: always falsy default if possible
always TypeOrValueSpecifier, never string names
standardized names: not just no no-, but allow/check*
rule messages: be explicit about intent. E.g. rather than just "A record is preferred over an index signature", also mention it's for stylistic consistency.
No subjective, prescriptive, blurry-line rules. e.g. cyclomatic complexity, max-file-size/lines, etc.
automatic config migrations for deprecations and major versions if possible. see tslint-to-eslint-config
-> if possible means your config must be in a nice statically analyzable format.
maybe implement alongside eslint-nibble
maintain non-zero and positive relationships with both the community with neighbors. "coopertition"
rule options always include: description, why, why not, incorrect+correct examples tabs
thorough faqs, alongside glossary and troubleshooting
clearly delineated areas of plugins for useful things not core to most projects. e.g. lint rules that replace typescript functionality
Nested key in config for monorepo support
Only allow object schema types, and use Zod
Use TypeOrValueSpecifier, never general strings
Require rationale and invalid/valid table for all rules + options
Require 'when not to use it' for all rules
Aggressively prune legacy behaviors with deprecation in one major, removal in next - providing migrations if possible. Net positive for maintenance.
Built-in capturing all uses in supermajority of GitHub projects: md, yml, json (+1 eslint itself), also regex, sorting...
Community org capturing all common uses.
have them out of the box be a dpeendnecy of the linter? maybe not doable, but at least provided in config-initializer?
clearly delineate matrix of:
• logic vs. style
• common vs. strict
Rule message guidelines.
• Always be explicit on whether it's a stylistic, best practice, likely bug, etc.
No 'prefer-', 'no-', etc. in rule names. Pithier, less churn.
--interactive mode. for each issue:
• opens in your editor
• surfaces rich docs in the terminal
• have common resolutions & such shown
see elm and rust super nice compiler errors
There was a problem hiding this comment.
http://localhost:3000/rules/prefer-optional-chain#allowpotentiallyunsafefixesthatmodifythereturntypeiknowwhatimdoing - belies a need to be able to switch messageId fixers from suggestion to fix or vice versa. would be nice for codemods. requirement: all rules use messageIds, not raw message text.
|
|
||
| This is how I would choose to build a linter in 2024. | ||
|
|
||
| ### TypeScript Core |
There was a problem hiding this comment.
I'm going to split this out into its own blog post. It's much more dev-friendly as a subject area. And I want it as its own standalone discussable (set of) point(s).
JoshuaKGoldberg
changed the title
PR Checklist
status: accepting prsOverview