Deno: Replace ESLint with dlint for development

[bartlomieju]

Currently in development of deno we use ESLint to lint JavaScript and TypeScript code. Additionally std/ and cli/tests/unit are linted using deno lint as integration tests.

In deno_lint repository we have a small example binary called dlint that is essentially a small CLI on top of deno_lint crate (which is used as a basis for deno lint subcommand). There exists an issue to provide prebuilt dlint binaries on new releases of deno_lint crate (https://github.com/denoland/deno_lint/issues/367).

I propose we switch from ESLint to dlint to do linting during development for the following reasons:

• remove Node dependency on ESLint (it's part of deno_third_party git submodule); I think ESLint is our last Node dependency and we could remove Node altogether Node is used in benchmarks
• more dogfooding of deno_lint
• dlint is significantly faster that ESLint

If we agree to do that then the order of action is as follows:

• set up releases of dlint - https://github.com/denoland/deno_lint/issues/367
• release dlint binary with next deno_lint crate version
• add dlint binary to deno_third_party repository
• change tools/lint.py to use dlint binary instead of ESLint
• remove ESLint from deno_third_party

CC @ry @kitsonk @lucacasonato @nayeemrmn @caspervonb

[nzakas]

Just curious, is there anything the ESLint team can do to it easier to use ESLint? It seems like the Node.js dependency is the big issue?

[bartlomieju]

@nzakas thanks for reaching out, I think there's really nothing ESLint could do at this point. We are working on our own linter written in Rust called deno_lint which has been available in Deno for a few months now.

This issue regards only internal code that gets built into the binary itself and would help to limit our dependence on Node.

I would be however interested in collaborating with ESLint team to allow using deno_lint's parser in ESLint which is significantly faster than estree (and produces similar AST).

[bartlomieju]

denoland/deno_lint#367 has been resolved and dlint binaries are now available to download from GitHub release page.

We can now proceed to migrate tools/lint.py to use dlint instead of eslint - one note is that currently dlint requires to explicitly pass --script argument when linting scripts (= not ES modules) so tools/lint.py should run dlint on cli/rt/ with --script flag and without it for the rest of files.

[nzakas]

@bartlomieju ah ok, thanks for the additional details.

I’d definitely be interested in collaborating to see what it would take to get your parser working in ESLint. The best way to get started is to open an issue in the eslint repo with a description of how the parser works and what sort of compatibility issues you know of.