On Saturday, December 14, 2013 12:51:25 PM UTC-5, Nicholas Zakas wrote: > > Mistakenly replied only to Ilya, forwarding to the list. > > -N > > Sorry for the late reply. More stuff inline... > > > On Fri, Dec 6, 2013 at 3:00 PM, Ilya Volodin 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 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. > > I did create an example a while back, it's checked in here: https://github.com/ilyavolodin/eslint/tree/context-identifiers The code in eslint has changed a lot since it was checked in, so it would be tough to merge it in, but it's easy to re-write it. The reason I don't want to mark frameworks per file/project is because I want the rules to only apply to the right context. For example, I would like to have a rule for Backbone that would require every Backbone.Model to have defaults specified, and I would also like defaults to be the first node inside Model. While I can mark the whole file as Backbone.Model, if I have some unrelated code in that file, it would also be checked for the same rule, which would be incorrect. I guess in a lot of cases something like esquery would help implement the same exact behavior as what I'm talking about.
I would also like to see what the others think about this idea. > >> >>> * 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? > Completely agree on performance, however, I think it's a given that if you want to parse more files, performance will suffer. Also, some of this can be solved by smart caching and management of the files that need to be processed. For example, if file A depends on file B, but file B also needs to be linted (part of the directory that is being linted), performance shouldn't suffer greatly if we lint B first and A after. Just need an ability for eslint.js to create a global singleton dictionary that would map files to variables, and process files in correct order. > > >>> >>>> * 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. > > Uploaded here: https://docs.google.com/spreadsheet/ccc?key=0At6DZUsxLY1TdDlzaDlQVGg4R19NTDhvcEV1eHlOYWc&usp=sharing. See if you can figure out more from it then I could. Thanks, Ilya Volodin -- 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.
