deno_lint VS ESLint

Fast compilation seems very appealing. It is one of the main reason why I am interested into Go and Zig.

I recently started working with Rust for contributing to projects like Rome/tools [1] and deno_lint [2]. The compilation and IDE experience is frustrating. Compilation is slow. I am afraid that this is rooted to the inherent complexity of Rust.

[1] https://github.com/rome/tools

[2] https://github.com/denoland/deno_lint

Though, for large scale projects, I’d wait until https://github.com/denoland/deno_lint/issues/303 is done; if they tackle that, they tackled types, and that’s the single big thing yet to tackle.

There isn't any uniformity that could be reasonably achieved once plugins are added to a linter. Someone will always want an edge case for their project covered even if it's not in the uniform configuration; most large projects either use plugins or custom rules outside of what ESLint provides. Deno understands this too given that plugin support is being considered.

Deno's lint config is under deno.json or deno.jsonc and is limited to the following rules: https://lint.deno.land/

$ deno lint (prefer-const) `order` is never reassigned let order = new Order() ^^^^^ at /Users/dina/try-deno/design-patterns/state.ts:106:4 hint: Use `const` instead help: for further information visit https://lint.deno.land/#prefer-const Found 24 problems Checked 25 files

I built one of the tools mentioned in the article, Deno's linter. Its binary is over 30 MiB:

After a long time, I started contributing to open-source software. For a long time, I had my eye on Deno. This week, I merged my first PR in Deno Lint. Following is the detailed post about the issue.

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.

ESLint

1. Lack of Static Code Analysis Static code analysis tools like TypeScript and ESLint play a crucial role in identifying and preventing bugs. TypeScript provides static typing, enhancing the robustness of the code. ESLint detects issues and enforces coding standards. The absence of these tools can significantly elevate the likelihood of bugs due to the lack of early detection and guidance provided during development.