On Friday, December 6, 2013 11:12:56 AM UTC-5, Nicholas Zakas wrote:
>
> 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]<javascript:>
> > 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.
>

I want something a bit different then hardcoding frameworks in global 
config. If I were to mark that I'm using Backbone in environments, it will 
apply to all files that I'm linting. Even if I mark it through comments on 
top of a given file, file might contain code that uses Backbone, and code 
that does not. I would like context identifiers to work more or less the 
same way as rules to. I would subscribe to a given node type, but instead 
of returning an error, I would return a framework used. Then all of the 
children nodes of that node will have access to check which framework is 
used. More then that, I could filter out rules that way, if the rule is 
marked as Backbone rule, I would run it only on nodes that are marked as 
children of Backbone node identifier, but not on any other node. I don't 
think we need to provide many context identifiers ourselves, but opening 
API to allow users to write custom ones would be very good move in my mind. 
I know I would use it myself for some Backbone Model/Views and jQuery 
specific rules.
 

>  
>
>> * 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.
>

Agree. But I think it should be on the roadmap for some future release. 

>  
>
>> * 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.  
>
 
>
I will add tickets as I come up with ideas, but maybe we should create a 
separate document or something to track those?
 

> * 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?
>

This is a requirement for my company to switch over to start using ESlint. 
We are currently using JavaScriptLint which, unlike JSLint/Hint doesn't ask 
for list of global variables. Instead you put comment on top of the file 
with a url, that says that this script depends on the other file. When 
linter runs, instead of reading globals from comments, it runs through 
the file your script is dependent on first and extracts all global 
variables, those are then used as globals for a given file. I think you 
should be familiar with the process, I think it was already implemented 
before you left the company.

* 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.
>

I can dump all perf logs somewhere for people to use, since the only 
available profiler for node currently runs on Windows only. Granted, Visual 
Studio Profiler doesn't output very readable results... The only thing that 
I could spot was getTockens calls en mass. 

>  
>
>> * 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 
>
 
>
While this is doable, it's inconvenient for CI integration. However, this 
is not a huge issue, since Grunt task can generate a file with the output.

>
>> 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.

Reply via email to