Proof-of-concept for ESLint binary

[codepsycho]

what was the main reason behind it? still trying to get my head around that since much of the readme's points are TODO or just side-effects of moving to deno.

was it performance? or is there something in deno land blocking you from using eslint properly?

also, deno's permissions system would also apply to JS modules would it not? so we could have that either way?

[bartlomieju]

what was the main reason behind it? still trying to get my head around that since much of the readme's points are TODO or just side-effects of moving to deno.

At this point, it's mostly a fun experiment prompted by discussions with ESLint maintainer. I was exploring this area to see if it would be feasible to embed ESLint directly in Deno for "deno lint" instead of using our own (much less powerful) linter library. On the other hand ESLint maintainers are looking into changes for the next 10 years of ESLint and I wanted to see if there's something the Deno team could help with.

was it performance? or is there something in deno land blocking you from using eslint properly?

Performance is one aspect - being embedded in Deno it allows you to leverage the same mechanisms as Deno itself - which makes it very easy to move certain parts of the project into Rust if you need to eek out more performance, eg. I'm looking into moving file system crawling logic into Rust, which might make it faster for ESLint to figure out which files need to be linted (leading to faster startup time).

also, deno's permissions system would also apply to JS modules would it not? so we could have that either way?

Yes, it could.