Yes, I'll work on doing that. Some initial thoughts on these things:
On Thu, Dec 5, 2013 at 7:54 PM, Ilya Volodin <[email protected]> wrote: > > * I'm still very interested in context identifiers for different > frameworks. While I think that adding framework specific rules to the main > distribution is not necessary, being able to detect framework and then run > custom rules could be incredibly powerful thing that is not covered by any > linting tool currently available. > I'm curious if this could be handled similar to what we're doing with environments now? The only thing I'm not sure of it framework detection - I tend to think that asking people to specify the frameworks they're using is safer (for example, what if we detect wrong?). But in the vein of enabling certain rules per framework environment seems pretty straightforward. > * Ability to disable rules per line > To me, this is a nice-to-have at the moment. We have a larger problem of figuring out how to deal with comments and lines that I think needs to be solved first. > * More complicated selectors for rules (cssauron, esquery/esdispatch, etc.) > Yes, definitely interested in looking at this soon-ish. > * More rules (and definitions for what they should be/do) > Yes, please feel free to file issues for any rules you think belong. In my mind, adding more rules is an ongoing thing that happens all the time. > * Ability to not only define global variables, but declaring dependency on > another file > I'm not sure what you mean here. Can you explain more? > * Something to make adding custom rules easier (maybe through npm or > something else) > Agree. I've been looking at the way Yeoman deals with custom generators as a possible model for this. > * Performance (I finally was able to run the code through the profiler for > the first time yesterday, or rather, I finally was able to find a full > fledged profiler for Node.js) > Dear god, yes. My biggest concern in this regard is the number of traversals we need to do for each file we lint. I think it ends up being 4 (one for escope, one to attach comments, one to attach tokens, and one for the main traversal that applies rules). Most of the rules seem pretty fast, it's just the fact that we keep doing traversals over the same AST that starts to add up. I'd love to figure out a way to eliminate the extra traversals. > * A way to output results to a file, instead of command line > I'm not sure this is necessary, as you can just pipe the output to a file: eslint foo.js > results.txt > > Thanks, > > Ilya Volodin > > On Thursday, December 5, 2013 9:10:36 PM UTC-5, Nicholas Zakas wrote: > >> Hi all, >> >> Just a heads up to say that I've published a new version to npm. This >> includes a number of bug fixes. The complete changelog is here: >> https://github.com/nzakas/eslint/commit/f88445d5c27827711f10e6c75f5d81 >> 39bfc6ce49 >> >> Thanks for all the hard work! We're making a ton of progress. >> >> -- >> >> ______________________________ >> Nicholas C. Zakas >> @slicknet >> >> Author, Professional JavaScript for Web Developers >> Buy it at Amazon.com: http://www.amazon.com/Professional-JavaScript- >> Developers-Nicholas-Zakas/dp/1118026691/ref=sr_1_3 >> > -- > You received this message because you are subscribed to the Google Groups > "ESLint" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- ______________________________ Nicholas C. Zakas @slicknet Author, Professional JavaScript for Web Developers Buy it at Amazon.com: http://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691/ref=sr_1_3 -- You received this message because you are subscribed to the Google Groups "ESLint" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
