Worked! What'd I'd like to understand the use case for having two different linters with two different configurations in the same process. Can you explain what you have in mind?
It sounds like all of the other issues are more related to this one rather than standalone. Some random thoughts related to this: * The context object is designed to be an abstraction that doesn't have to change its interface (thus, rules will continue to work). We have the ability to change what the context object binds to whenever we want without requiring subsequent changes to rules. All that matters is that the interface remains the same. It doesn't have to pass through to the main ESLint object as it does now (yay abstractions). * I'm not opposed to having a constructor for a linter, but I want to understand a real use case if we're going to make this big of a change. Saying "I want to" is different than saying "I need to". * I am opposed to passing the AST around. I don't want to force people to create an AST and pass it in, if for no other reason than we may not use Esprima long-term and want to hide the AST producer details from any consumers of ESLint. * The internal state is currently cleared after each run. Since each run is done synchronously, that protects against scope leakage. You can alternately choose to save state, but that's mostly for testing purposes. On Wed, Nov 20, 2013 at 10:37 AM, Michael Ficarra <[email protected]>wrote: > Crap, my first message didn't go through. Trying again, but I had to > re-type, and it's never as good the second time around. > > Link to the original discussion, since I have slightly expanded my > proposal since initially posting it: > https://github.com/nzakas/eslint/issues/395#issuecomment-28862653 > > (1) is by far the most important point; (2) is one way to get there. > Regarding (3), I understand that [a context object is being passed to the > rule creation function][0], but it's [passing through certain methods][1] > to *the module itself*, which keeps execution state and is constantly > mutating. That's the same problematic design that I'm trying to fight with > (1), and which is giving me trouble when trying to switch out estraverse > for esdispatch. Regarding (4), that is just one of many possible > interfaces. In my expanded example, I also show an event-based interface > and a synchronous interface, and all of these interfaces can live > side-by-side. > > > [0]: > https://github.com/nzakas/eslint/blob/3777ca6e2780666f7eb5f4abf3338e90fea5cefa/lib/eslint.js#L269 > [1]: > https://github.com/nzakas/eslint/blob/3777ca6e2780666f7eb5f4abf3338e90fea5cefa/lib/rule-context.js#L46-L51 > > > On Wed, Nov 20, 2013 at 11:33 AM, Nicholas Zakas < > [email protected]> wrote: > >> I want to try to restate what you (Michael) are saying in this post to >> see if I understand correctly: >> >> 1. You have a desire to have two different linters running within the >> same program with different configurations. >> 2. You would much rather instantiate a linter than have a singleton. >> 3. It seems like you're a bit confused about the rule of the context >> object in rules (I'm not quite sure what your last sentence means). >> 4. You would like the ability to run ESLint asynchronously (I'm assuming >> based on the callack to lint()). >> >> Did I get those right? >> >> >> On Wed, Nov 20, 2013 at 8:53 AM, Nicholas Zakas < >> [email protected]> wrote: >> >>> Pasting from Michael Ficarra's message in the GitHub issue: >>> >>> >> >>> >>> I was referring to basically what I covered in >>> #205<https://github.com/nzakas/eslint/issues/205>. >>> The eslint interface is quite frankly unusable. I can't pass two >>> preconfigured linters to two separate functions for them to run on two >>> separate programs. I can't configure a linter and then run it on a program >>> in a continuation because I can't guarantee some other event in the loop >>> hasn't either run it on a different program or reset it. This would be a >>> much better interface: >>> >>> var eslint = require('eslint'); >>> // generate a linter that has no rules enabled >>> var linter = new eslint.Linter; >>> // enable the default rules with the default options >>> linter.useDefaultRules(); >>> // enable another rule >>> linter.use(eslint.rules[someRuleName], {severity: eslint.WARN}); >>> // a custom rule >>> linter.use(function(context){ /* rule generator, just like today */ }, /* >>> options */); >>> // run it! >>> linter.lint(esprima.parse(js), function(lintingError, listOfViolations, >>> listOfWarnings) { >>> // as long as there was no lintingError, do something with the >>> listOfViolations and listOfWarnings >>> }); >>> // other instances have nothing to do with the first one >>> var anotherLinter = new eslint.Linter; >>> >>> Also, the rules themselves have to get passed an actual context object >>> instead of a reference to the module itself, which is constantly mutating. >>> >>> -- >>> >>> ______________________________ >>> 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. >> > > -- ______________________________ 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.
