A few comments.. I'm not sure how this will work for the following scenarios:
* I'm creating a new package, and would like to include eslint as a default linter. I would also like to get some custom rules working (My understanding is that I would just include custom rules into package.json in this case) * I'm creating a new package that relies on the package that uses eslint and custom rules. I would like to use that installation of eslint with custom rules, can I do that? * I'm writing client-side code and would just like to use eslint + custom rules. I installed eslint globally, where do I do npm install custom-rules from? Also, my other concern is that this method requires modification of eslint.config or .eslintrc file every time I add a new set of rules. It's not a huge problem, but it would be nice if I could instead have a set or rules an eslint.config file that would be merged into main eslint.config on execution. Maybe when executing eslint, I would pass all of the configs in. Thanks, Ilya Volodin On Monday, December 23, 2013 4:51:14 PM UTC-5, Ian Christian Myers wrote: > Here’s a rough, high-level proposal for how we could approach > incorporating custom rule sets. I would love feedback on whether this is > the right direction and, if it is, how it can be improved: > > https://github.com/nzakas/eslint/wiki/Custom-ESLint-Rule-Sets > > Best, > > Ian > > On Dec 23, 2013, at 8:34 AM, Ian Christian Myers > <[email protected]<javascript:>> > wrote: > > Yes! I'll give it a look and see what I can come up with. > > -Ian > — > Sent from Mailbox <https://www.dropbox.com/mailbox> for iPhone > > > On Mon, Dec 23, 2013 at 8:15 AM, Nicholas Zakas > <[email protected]<javascript:> > > wrote: > >> I agree - that's not fully thought out yet. I'd like to look at how >> Yeoman allows you to create generators as a starting point for a model of >> sharing rulesets. Do you want to take a look and come up with a proposal >> for doing so? >> >> -N >> >> >> On Mon, Dec 23, 2013 at 8:10 AM, Ian Christian Myers >> <[email protected]<javascript:> >> > wrote: >> >>> I've been thinking about this topic recently as well. In addition to >>> improving the development infrastructure in the ESLint community, I think >>> we also need to figure out a better way to plug in custom rule sets and >>> keep them up to date. Right now, the process seems to be checkout a rule >>> set, add the keys to .eslintrc, point eslint at those rules. But what >>> happens when I'm using 2 custom rule sets? 3? It can get messy quickly. >>> >>> Best, >>> >>> Ian >>> — >>> Sent from Mailbox <https://www.dropbox.com/mailbox> for iPhone >>> >>> >>> On Mon, Dec 23, 2013 at 7:59 AM, Nicholas Zakas < >>> [email protected] <javascript:>> wrote: >>> >>>> Hi all, >>>> >>>> Some thoughts I wanted to share. In thinking about how to move ESLint >>>> forward in 2014, I had some ideas I wanted to share. >>>> >>>> I'm hoping and anticipating that people will create custom rulesets >>>> that they will want to share. I can envision people using GitHub to put >>>> these rulesets into repos that are shared by others. I also imagine that >>>> these repos would be setup similar to the main ESLint repo, with rules and >>>> tests for those rules. That also means the workflow for these repos would >>>> be similar to those of creating new rules for ESLint itself. >>>> >>>> I can also envision similar things for formatters (we're already seeing >>>> a bit of that). >>>> >>>> So, what do we need to do enable this use case and make things more >>>> efficient? Here's what I have in mind: >>>> >>>> 1) Separate out ESLint Tester into its own npm package. That way, it's >>>> easy for custom rulesets to use it to write tests. >>>> 2) Create a Yeoman generator that will scaffold out rules and >>>> formatters, as well as rulesets, including appropriate test and >>>> documentation stubs. >>>> 3) Create an ESLint organization on GitHub under which these three >>>> projects (including the main ESLint repo) are located. >>>> >>>> I think this will make ESLint easier to use and, hopefully, encourage >>>> more people to participate in its development. >>>> >>>> Thoughts? >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> ______________________________ >>>> 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] <javascript:>. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> >>> -- >>> 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] <javascript:>. >>> 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] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > -- 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.
