Roadmap

[bartlomieju]

Opening this issue for tracking purposes as well as to better communicate what can be expected of deno_lint in the near future.

Here are the issues that current development focuses on (in the order it must be implemented):

• Scopes analysis Finish scope analysis #160 - requirement for any "more advanced" rule
• ESLint recommended rule set ESLint recommended rules #48
• typescript-eslint recommended rule set typescript-eslint recommended rules #86

Next:

• better rule description and diagnostics Feature request: Add suggestion(s) to error messages #162 Add descriptions and examples to each lint rule #159
• basic configuration - need ability to enable/disable rules for project (feat(lint): add support for config file and CLI flags for rules deno#11776, First pass at config file deno#11686)
• plugin support discussion: plugin support #175 - mechanism for providing new rule sets - follow feat(lint): add JavaScript plugin support deno#27203 for updates

Future:

• documentation website
• use deno_lint from Node project Feature Request: Webpack Loader for Deno Lint #169
• autofix

[bartlomieju]

Update: recommended set of rules from ESLint and typescript-eslint have been implemented.

We can now proceed to working towards better diagnostics and suggestions for lint rules as well as tentatively working on rudimentary configuration.

[4ldas]

I dont think the development team should use issues for tracking reasons, there is projects and readme or other markdown files or such that should be used instead in my opinion.

[JLarky]

I'm pretty ignorant on the topic, but would you be able to use deno linter in VSCode for nodejs/webpack projects? :) I tried to look up the answer and so far it looks like it would only work with this plugin and only for deno project.

[magurotuna]

@JLarky As far as I know, there's no extension that makes it possible for deno_lint to be integrated into VSCode for Node projects. But I would say that technically it could be realized.

[JamesHenry]

Creator of @typescript-eslint here 👋

I stumbled upon this project via a tweet.

I’m just curious, were any experiments undertaken to try and ingest rules as they exist today (in TS) but execute them in rust?

ie replace the ESLint libraries but keep the existing low barrier to entry authoring experience (and 10000s of hours of already invested dev time in existing rules and plugins).

[bartlomieju]

Hey @JamesHenry, thanks for dropping by!

I’m just curious, were any experiments undertaken to try and ingest rules as they exist today (in TS) but execute them in rust?

I'm not sure I understand the question, but let me try to answer anyway. Initially, before the inception of this project we explored the idea of using eslint directly by running it in Deno, however we were unsuccessful in producing something a'la browser build (nor did we find such build, let me know if it exists). From my understanding typescript-eslint is a plugin to eslint that additionally leverages TSC to be able to operate on TS's types (for rules such as no-floating-promises).

Providing similar functionality in Rust would require to have implementation of TSC in Rust, which currently does not exist (although I know @kdy1 is working on it).

We also explored idea of AST parsing in Rust using swc and converting it to a eslint compatible AST. This approach is feasible, however it circles back to the problem of not having browser build of eslint.

deno_lint hasn't received a lot of attention in the last couple months because of major works in deno repo, but we still want to develop it further and I'm more than happy to discuss pooling efforts.

[JamesHenry]

Yeah it was a genuinely open question - I haven't thought about it in any detail and I also don't know that much about rust or deno :)

I do know of interesting experiments involving mixing JS tooling with rust and was genuinely just curious if there are ways to achieve the best of both worlds for linting too.

So yeah nothing more from my side on this but I'll keep thinking about it - I have a good reason to dig into rust more at work now so hopefully that will inform my thinking as well.

[RDambrosio016]

Ive juggled with the idea of reusing js rules for a project i am making too and i eventually reached a conclusion of "its too hard and limits things too much" for the following reasons:

• Most users don't use "esoteric" rules from random plugins beyond popular ones like vue, react, import, and typescript, which i believe should be supported natively by the linter.
• It limits performance optimizations way too much. Js is single threaded, having to spawn an entirely new vm and its friends for every file you want to lint on a separate thread incurs too much of a memory and performance loss to make it viable.
• It's not good to rely on the stability of one project from a project in a completely different language with different opinions and an entirely different runtime altogether.
• It limits further prospects for a different type checker.
• It forces you to conform to an API you have no control over without being able to change it because of stability concerns in eslint.
• Js' dynamic nature limits semantic understanding of rules, for example, you can provide a typed json schema for the config if you know what the rule expects for options. This is incredibly easy in rust using typetag + serde.

[l-cornelius-dol]

Also needed is the ability to define a global set of rules, not just per project. Per project rules should override (fully replace) the global rule set. Per file excludes (using // deno-lint-ignore-file ...) add to the the project excludes.

A possible nice enhancement would be to add // deno-lint-include-file to add to the project includes. And if done, // deno-lint-ignore-file should be deprecated for // deno-lint-exclude-file.

[shellscape]

Lots of great things happening around this project and it's great to see. I wanted to stop in here and very gently add some feedback into the pool. Since our entire team is coming to Deno from very deep Node experience, and years of experience with ESLint+Prettier, the bar the org is using for whether or not to adopt deno_lint is ESLint; the configurability and ability of ESLint. The closer deno_lint can get to that, I think the easier a switch to it will become for a lot of folks. (We like that deno_lint is opinionated, similar to how Go does things, but the ability to fine tune is something we're all accustomed to)

[bartlomieju]

Lots of great things happening around this project and it's great to see. I wanted to stop in here and very gently add some feedback into the pool. Since our entire team is coming to Deno from very deep Node experience, and years of experience with ESLint+Prettier, the bar the org is using for whether or not to adopt deno_lint is ESLint; the configurability and ability of ESLint. The closer deno_lint can get to that, I think the easier a switch to it will become for a lot of folks. (We like that deno_lint is opinionated, similar to how Go does things, but the ability to fine tune is something we're all accustomed to)

Thanks for feedback, could you give some more concrete examples of what you want to fine tune?

[traceypooh]

there just doesn't seem to be enough optional rules (from what i can find) effectively replace eslint fully.

some example we're using and quite love, based on airbnb-base w/ eslint:

• quotes
• no-useless-concat
• max-len

i'm trying to migrate [a lot] of code from node to deno (project w/ 30,000+ lines JS)
and trying to make lines be node/eslint or deno agnostic with line-by-line comments like:
/* eslint-disable-next-line no-empty */ // deno-lint-ignore no-empty

which works nicely. but i'm finding there are many rules we use/rely on w/ our team that dont seem to have deno complements (again, best i can tell). The above was just a few of them.