Mistakenly replied only to Ilya, forwarding to the list. -N
---------- Forwarded message ---------- From: *Nicholas Zakas* Date: Friday, December 13, 2013 Subject: Version 0.1.4 released To: Ilya Volodin <[email protected]> Sorry for the late reply. More stuff inline... On Fri, Dec 6, 2013 at 3:00 PM, Ilya Volodin <[email protected]<javascript:_e({}, 'cvml', '[email protected]');> > wrote: > > > 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]> 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. > I'm still not sold on this, primarily because it sounds like a pretty complex mechanism. In my mind, a framework being used is an environment that can have either project or file scope. If a file is using Backbone, as you said, then I don't think it make sense to say only part of the file is using Backbone since the entire file has access to the globals that Backbone exports. All this said, if you want to throw together a more complete proposal including what code would look like and some practical use cases, I'll leave myself open to be convinced. > > >> >> >>> * 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. > Agreed. >> >>> * 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? > We could make it a separate sheet on the rules list we have in Google Docs right now. > > >> * 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. > > Oh wow, you're still using that? :) I'm a bit concerned about the performance implications of this, as I think we'd have to parse and escope a second file before linting the actual file. Maybe we need a separate command that will extract globals from a file and output them so you can copy into a config? >> >>> * 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. > That would be great. -- ______________________________ 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 -- ______________________________ 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.
