feat: blog: Differences between linting and type checking #664
Conversation
✅ Deploy Preview for es-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for ja-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for new-eslint ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
| // ~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| // eslint(jsx-a11y/alt-text): | ||
| // img elements must have an alt prop, either with meaningful text, or an empty string for decorative images. | ||
| ``` |
There was a problem hiding this comment.
[Question] Is there a preferred strategy for showing ESLint rule reports in code blocks within blog posts?
✅ Deploy Preview for hi-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for zh-hans-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for fr-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for de-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for pt-br-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| console.log("🍌"); | ||
|
|
||
| // eslint(no-fallthrough): | ||
| // Expected a 'break' statement before 'case'. |
There was a problem hiding this comment.
I don't love this first example:
- It's pretty verbose
- It doesn't show something that's clearly, definitely a valuable report ("what if I want to break through, that's too opinionated!")
...but I couldn't find a better lint rule that:
- Produces clear valuable report on a likely bug
- Is in
js.configs.recommended - Isn't superseded by TypeScript
Seeking inputs on a better example to show!
| ## Differences in Purpose | ||
|
|
||
| Type checkers make sure the *intent* behind values in code matches the *usage* of those values. | ||
| They check that code is "type-safe": meaning values are used according to the ways their types describe as being allowed. |
There was a problem hiding this comment.
| They check that code is "type-safe": meaning values are used according to the ways their types describe as being allowed. | |
| They check that code is "type-safe": values are used according to how their types are described as being allowed. |
| Each lint rule can be granularly configured. | ||
| If you don't like a particular lint rule, you can always turn it off for a line, set of files, or your entire project. | ||
|
|
||
| Linters can also can be augmented by **plugins** that add new lint rules. |
There was a problem hiding this comment.
| Linters can also can be augmented by **plugins** that add new lint rules. | |
| Linters can also be augmented by **plugins** that add new lint rules. |
|
|
||
| Linters and type checkers operate differently and specialize in different areas of code defects. | ||
| Some code defects straddle the line between "best practices" and "type safety", and so can be caught by both linting and type checking. | ||
| There are some core rules in that are superseded by TypeScript's type checking. |
There was a problem hiding this comment.
| There are some core rules in that are superseded by TypeScript's type checking. | |
| There are some core rules that are superseded by TypeScript's type checking. |
| They additionally ignore parameters that come before any parameter that is itself used. | ||
|
|
||
| Some projects prefer to never allow unused parameters regardless of name or position. | ||
| That stricter preferences helps prevent API designs that lead developers to creating many unused parameters. |
There was a problem hiding this comment.
| That stricter preferences helps prevent API designs that lead developers to creating many unused parameters. | |
| These stricter preferences help prevent API designs that lead developers to create many unused parameters. |
| ### Linters, With Type Information | ||
|
|
||
| Traditional lint rules run on a single file at a time and have no knowledge of other files in the project. | ||
| They can't make decisions on files based on contents of other files. |
There was a problem hiding this comment.
| They can't make decisions on files based on contents of other files. | |
| They can't make decisions on files based on the contents of other files. |
There was a problem hiding this comment.
Ran out of time so just left some comments on the first bits. Overall, I think we need to work on clearing up the language and the message. I'll continue looking tomorrow.
I'd also like to pull out adding support Bluesky social links into a separate PR as it's not really related to the article.
| @@ -16,7 +16,7 @@ | |||
| </p> | |||
| </div> | |||
|
|
|||
| <div class="profile__social-links"> | |||
| <div class="profile__social-links a "> | |||
There was a problem hiding this comment.
Can we pull these changes out into a separate PR?
| @@ -45,7 +45,9 @@ | |||
| title: all_authors[author].title, | |||
| handle: all_authors[author].username, | |||
| github: all_authors[author].github_username, | |||
| bluesky: all_authors[author].bluesky_url, | |||
There was a problem hiding this comment.
Same, let's pull out into a separate PR.
| - Linting | ||
| --- | ||
|
|
||
| Linters and type checkers are two kinds of tools that both analyze code and report on detected issues. |
There was a problem hiding this comment.
I think we need a bit more in the intro. This is a bit abstract, and I think could use some grounding in reality. Something like, "If you're a JavaScript developer today, you're probably using TypeScript or ESLint, or both..."
|
|
||
| ## Definitions | ||
|
|
||
| *"Static analysis"* is the term for tooling that checks code for issues without running it. |
There was a problem hiding this comment.
Stylistically, let's just use italics when introducing new terms (no quotes).
Also, static analysis isn't tooling, it's what the tooling does, so probably more accurately:
| *"Static analysis"* is the term for tooling that checks code for issues without running it. | |
| *Static analysis* is the inspection of source code without executing it. This differs from *dynamic analysis*, in which source code is inspected while it is executed. As such, dynamic analysis brings with it the inherent danger of executing malicious code or creating side effects while static analysis is safe to execute regardless of the source code. |
| They may seem similar at first. | ||
| However, the two kinds of tools detect very different issues and are useful in different ways. | ||
|
|
||
| ## Definitions |
There was a problem hiding this comment.
I think I'd like to make this more conversation that just listing definitions.
| ## Definitions | |
| ## What is static analysis? |
| *"Static analysis"* is the term for tooling that checks code for issues without running it. | ||
| There are three forms of static analysis commonly used in web development projects today: | ||
|
|
||
| 1. **Formatters**: only print your code quickly, without worrying about logic |
There was a problem hiding this comment.
I'm not sure formatting belongs in this list. Unlike linters and type checkers, formatters don't return a list of things to know about code. For the purposes of this article, I'd say we can safely omit this.
| ## Definitions | ||
|
|
||
| *"Static analysis"* is the term for tooling that checks code for issues without running it. | ||
| There are three forms of static analysis commonly used in web development projects today: |
There was a problem hiding this comment.
I'd add another paragraph here explaining the value of static analysis for catching problems before moving on to discuss linters and type checkers.
| 2. **Linters**: execute individually configurable checks known as "lint rules" | ||
| 3. **Type checkers**: collect all files into a full understanding of the project |
There was a problem hiding this comment.
I don't think these descriptions are accurate. You're describing how ESLint works and how TypeScript works, but that doesn't necessarily mean all linters and type checkers work like this.
I'd focus instead on linting as the systematic evaluation of patterns in the structure of source code (maybe even briefly describe the original C lint tool) while type checking is an evaluation of data flow throughout the program.
Prerequisites checklist
What is the purpose of this pull request?
Adds the blog post per #663.
What changes did you make? (Give an overview)
The post explains:
noUnusedLocalsandnoUnusedParametersIn adding myself as an author, I noticed there wasn't yet support for Bluesky URLs. So I added that in too. I can split that out if preferred.
Related Issues
Fixes #663.
Is there anything you'd like reviewers to focus on?