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?
There was a problem hiding this comment.
We don't have one, so I think this is fine.
✅ 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!
There was a problem hiding this comment.
no-unused-vars? Although I guess TypeScript is now flagging that, too.
no-unexpected-multiline?
There was a problem hiding this comment.
Yeah, and no-unexpected-multiline is pretty much made unnecessary by formatters... sigh
There was a problem hiding this comment.
Then I think this is fine to leave as-is.
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
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.
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
| 2. **Linters**: execute individually configurable checks known as "lint rules" | ||
| 3. **Type checkers**: collect all files into a full understanding of the project | ||
|
|
||
| We'll focus in this blog post on *linters*, namely ESLint, and *type checkers*, namely [TypeScript](https://typescriptlang.org). |
There was a problem hiding this comment.
I think we might want to expand this section a bit because both ESLint and TypeScript do more than one type of static analysis. For instance, ESLint also does scope analysis and code path analysis, while TypeScript does linting, scope analysis, and type checking.
There was a problem hiding this comment.
🤔 what would the benefit of that be? Now that the following section reports examples of each, what's the new info we'd want readers to know going in?
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
After taking another look at this, I see two areas of improvement for this post:
- You need to decide whether you are talking about linters and type checkers generically, or ESLint and TypeScript, specifically. My recommendation is update the intro to talk about ESLint and TypeScript, take a step back to talk about what static analysis is generically, then explain which types ESLint and TypeScript use, and then continue on the rest of the blog post specifically talking about ESLint and TypeScript.
- Make sure to include examples when you're describing abstract concepts. A lot of the verbiage around static analysis will be unfamiliar to most readers (including "type-safe"), so grounding those descriptions with concrete examples is important.
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
| console.log("🍌"); | ||
|
|
||
| // eslint(no-fallthrough): | ||
| // Expected a 'break' statement before 'case'. |
There was a problem hiding this comment.
no-unused-vars? Although I guess TypeScript is now flagging that, too.
no-unexpected-multiline?
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Nicholas C. Zakas <[email protected]> Co-authored-by: Amaresh S M <[email protected]>
| logUppercase(9001); | ||
| // ~~~~ | ||
| // Argument of type 'number' is not assignable to parameter of type 'string'. | ||
| ``` |
There was a problem hiding this comment.
[Question] Is there a preferred strategy for showing TypeScript reports in code blocks within blog posts? (similar to the question about ESLint rule reports later on)
There was a problem hiding this comment.
We haven't done this in blog posts before, so I think this approach is fine.
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
src/content/blog/2024-12-04-differences-between-linting-and-type-checking.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Nicholas C. Zakas <[email protected]>
There was a problem hiding this comment.
I left suggestions throughout to clean up wording, simplify phrasing, and add more detail where I thought it was missing.
A couple high-level comments to pull out:
- I think this is really more about using ESLint and TypeScript together rather than the differences between a linter and a type checker. I think the title should reflect that. I made edits where I thought this line was getting blurry.
- Please go back through and ensure each section follows the same sequence of discussing linting and then type checking. You start by always discussing linting first, but halfway through switch to discussing type checking first. Keeping this consistent will help the reader keep their bearings throughout.
| --- | ||
| layout: post | ||
| title: "Differences between linting and type checking" | ||
| teaser: "Linters such as ESLint and type checkers such as TypeScript catch different areas of code defects — and are best used in conjunction with each other." |
There was a problem hiding this comment.
| teaser: "Linters such as ESLint and type checkers such as TypeScript catch different areas of code defects — and are best used in conjunction with each other." | |
| teaser: "Linters such as ESLint and type checkers such as TypeScript catch different areas of code defects and are best used in conjunction with each other." |
| - Linting | ||
| --- | ||
|
|
||
| If you're a JavaScript developer today, there's a good chance you're using ESLint and/or TypeScript to assist development. |
There was a problem hiding this comment.
| If you're a JavaScript developer today, there's a good chance you're using ESLint and/or TypeScript to assist development. | |
| If you're a JavaScript developer today, there's a good chance you're using a combination of ESLint and TypeScript to assist development. |
| Those two tools are common examples of their kind of tooling: ESLint is a common *linter*, whereas TypeScript is a common *type checker*. | ||
|
|
||
| Linters and type checkers are two kinds of tools that both analyze code and report on detected issues. | ||
| They may seem similar at first. | ||
| They both fall under the category of *static analysis*. | ||
| However, the two kinds of tools detect very different issues and are useful in different ways. |
There was a problem hiding this comment.
| Those two tools are common examples of their kind of tooling: ESLint is a common *linter*, whereas TypeScript is a common *type checker*. | |
| Linters and type checkers are two kinds of tools that both analyze code and report on detected issues. | |
| They may seem similar at first. | |
| They both fall under the category of *static analysis*. | |
| However, the two kinds of tools detect very different issues and are useful in different ways. | |
| These tools perform similar but different functions. ESLint is a *linter*, whereas TypeScript is a *type checker*. | |
| Linters and type checkers are two kinds of *static analysis* tool that analyze code and report on detected issues. While they may seem similar at first, the linters and type checkers detect different categories of issues and are useful in different ways. | |
| To understand these differences, it's first helpful to understand what static analysis is and why it's useful. |
| Many developers rely on static analysis to enforce consistent code formatting and style, to ensure code is well-documented, and to catch likely bugs. | ||
| Because static analysis runs on source code, it can suggest improvements in editors as code is written. | ||
|
|
||
| We'll focus in this blog post on ESLint and TypeScript: |
There was a problem hiding this comment.
| We'll focus in this blog post on ESLint and TypeScript: | |
| In this blog post, we'll focus on ESLint and TypeScript, and the different ways in which they perform static analysis. |
| * **ESLint**: executes individually configurable checks known as "lint rules" | ||
| * **TypeScript**: collects all files into a full understanding of the project |
There was a problem hiding this comment.
These two bullets don't seem to fit into the flow of this paragraph. They aren't a compare-and-constract pair, so I'm not quite sure what the reader takeaway should be here. Some options:
If the takeaway is the context of the analysis, maybe something like this:
ESLint and TypeScript collect data about your code in different ways. Whereas ESLint executes on one file at a time without any knowledge of others files, TypeScript works by first scanning the entire project to make cross-file associations.
If the takeaway is how analysis is organized, maybe something like this:
ESLint's static analysis is organized as a series of individually configured lint rules. Because no two rules interact with one another, you can safely turn each rule on and off depending on your preferences. While TypeScript has some individually configured options, the majority of the analysis is performed in the type checking functionality.
|
|
||
| ### ESLint, With Type Information | ||
|
|
||
| Traditional lint rules run on a single file at a time and have no knowledge of other files in the project. |
There was a problem hiding this comment.
| Traditional lint rules run on a single file at a time and have no knowledge of other files in the project. | |
| Traditional ESLint rules run on a single file at a time and have no knowledge of other files in the project. |
| ``` | ||
|
|
||
| Augmenting ESLint with information from TypeScript makes for a more powerful set of lint rules. | ||
| See [Typed Linting: The Most Powerful TypeScript Linting Ever](https://typescript-eslint.io/blog/typed-linting) for more details on typed linting with typescript-eslint. |
There was a problem hiding this comment.
I think we need to make mention that type-aware linting has performance implications.
| Augmenting ESLint with information from TypeScript makes for a more powerful set of lint rules. | ||
| See [Typed Linting: The Most Powerful TypeScript Linting Ever](https://typescript-eslint.io/blog/typed-linting) for more details on typed linting with typescript-eslint. | ||
|
|
||
| ### TypeScript, With Linting |
There was a problem hiding this comment.
| ### TypeScript, With Linting | |
| ### TypeScript with Linting |
|
|
||
| TypeScript adds extra complexity to JavaScript. | ||
| That complexity is often worth it, but any added complexity brings with it the potential for misuse. | ||
| Linters are useful for stopping developers from making TypeScript-specific blunders in code. |
There was a problem hiding this comment.
| Linters are useful for stopping developers from making TypeScript-specific blunders in code. | |
| ESLint is useful for stopping developers from making TypeScript-specific blunders in code. |
| * TypeScripts checks that code is "type-safe": enforcing what you *can* write | ||
| * ESLint checks that code adheres to best practices and is consistent: enforcing what you *should* write |
There was a problem hiding this comment.
| * TypeScripts checks that code is "type-safe": enforcing what you *can* write | |
| * ESLint checks that code adheres to best practices and is consistent: enforcing what you *should* write | |
| * TypeScripts checks that code is "type-safe", enforcing what you *can* write. | |
| * ESLint checks that code adheres to best practices and is consistent, enforcing what you *should* write. |
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?