JSDoc VS ESLint

You may like JSDoc[1] if you just want some type-safety from the IDE without the compilation overhead.

It’s done wonders when I’ve had to wrangle poorly commented legacy JavaScript codebases where most of the overhead is tracing what type the input parameters are.

Personally, I’m impartial to TypeScript or JSDoc at this point. But I’d rather have either over plain JavaScript.

[1] https://jsdoc.app/

I wholeheartedly agree. At most, I introduce JSDoc[1] to newer developers as standardising how parameters and whatnot are commented at least gets you better documentation and _some_ safety without adding any TS knowledge overhead.

[1] https://jsdoc.app/

This is where JSDoc comes to save the day.

The best way to do this, of course, is with JSDoc. But something I always found awkward about jsdoc is defining the object types in the same file. So, after a lot of reading, I found a way to combine JSDoc with declaration type files from Typescript. Let me give you an example:

There is a lot of specific symbols presented on the JSDOC specification that can be found here: https://jsdoc.app

JSDoc is a specification for the comment format in JavaScript. This specification allows developers to describe the structure of their code, data types, function parameters, and much more using special comments. These comments can then be transformed into documentation using appropriate tools.

Working with new features, frameworks, and tools, the experience of reading documentation is a critical part of it. I have been lucky to work with projects that feature really easy to read documentation such as USWDS and Bun, but I've also had the misfortune to work with pretty terrible documentation like JSDoc. The JSDoc documentation lacks a search field which makes searching for specific items an ordeal and also does not cover many hidden use cases. It provides less than the bare minimum for what it needs to do - a lot of the time I am forced to rely on external user documentation elsewhere to use JSDoc effectively. That was why I was drawn to the search field in particular in Docusaurus.

The Svelte team followed suit but motivated by the maintainer's developer experience as they migrated the project away from TypeScript in favor of plain JSDoc comments for type annotations instead.

Even more relevant, tools like Javadoc, JSDoc, Doxygen, etc. read comments in a specific format to generate documentation. These comments do not affect readability. On the contrary, Javadocs are great for explaining how to use these entities. Combined with tools like my dear Doctest, we even get guarantees of accuracy and correctness!

Document types with JSDoc annotations

Let's be honest - setting up tools for a new project can be a frustrating process. Especially when you want to jump straight to coding part. This is often the case with ESLint and Prettier, two popular tools in the JavaScript ecosystem that can sometimes interfere with each other when it comes to code formatting. Fortunately, there's a simple solution to this process, and it's called eslint-plugin-prettier.

Do you have the need to find and fix problems in your JavaScript? Then ESLint is for you. With over 120 million downloads each month, it's definitely one of the most popular projects out there. The latest version introduces a new configuration system, designed to simplify available configuration options. Old and deprecated rules have been removed, and a new configuration inspector has been added. Check out the blog for all the highlights, and a migration guide.

ESLint: A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript.

Automating code checks with static code analysis allows us to enforce code styling effectively. By integrating tools into our workflow, we can identify errors at an early stage, while coding instead of blocking us at the end. For instance, flake8 checks Python code for style and errors, eslint performs similar checks for JavaScript, and prettier automatically formats code to maintain consistency.

If you're a developer, you're surely familiar with Prettier and ESLint. With over 8 years of existence, they have established themselves as references in the JavaScript ecosystem.

eslint is used to avoid code errors

No lint errors: The committed code does not contain any lint errors (eslint).

Let’s walk through the steps for a one-time setup to configure husky pre-commit and pre-push hooks, ESLint with code styles conventions, prettier code formatter, and lint-staged. Husky automatically runs a script on each commit or push. This is useful for linting files to enforce code styles that keeps the entire code base following conventions.

GitHub | Website

ESLint: A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript.