That's my current line of thinking. I could be convinced otherwise, though (maybe you can specify a ruleset name like you can a package name?).
-N On Wed, Jan 1, 2014 at 12:32 PM, Ian Christian Myers <[email protected]>wrote: > I think this makes sense. For rules loaded via a directory path, would the > prefix in the keys be the last directory in the path? > > Best, > > Ian > — > Sent from Mailbox <https://www.dropbox.com/mailbox> for iPhone > > > On Tue, Dec 31, 2013 at 7:25 AM, Nicholas Zakas < > [email protected]> wrote: > >> What if we did a config like this? >> >> { >> rulesets: [ "ians-rules" ], >> rules: { >> "semi": 1, >> "ians-rules/custom": 1 >> } >> } >> >> So that the "rulesets" key indicates which rulesets to load and then >> place the rule in with all the others using a prefix? If you don't want to >> override any rule settings, then you don't need to specify anything but >> "rulesets" (and we probably need to output a warning to the console if a >> ruleset isn't found?). >> >> If we did this, then I think we'd also need to support full directory >> paths for rulesets, so in the above example, you'd look in >> node_modules/ians-rules, but if you provide a directory, we'd load it from >> there: >> >> { >> rulesets: [ "./my-rules" ] >> } >> >> Does that make sense? >> >> -N >> >> >> On Mon, Dec 30, 2013 at 1:43 PM, Ian Christian Myers >> <[email protected]>wrote: >> >>> My responses are inline below. >>> >>> Thanks for putting this together. A few thoughts and questions below. >>>> >>>> If I'm reading this right, the necessity of putting the ruleset name in >>>> the config file is so that ESLint know which directory to look for the >>>> custom rules, is that correct? >>>> >>> >>> This is correct. I think it also provides context around which rules >>> are coming from which set. >>> >>> With regards to configuration, I'm assuming that the custom ruleset >>>> has default configuration in its eslint.json file that will automatically >>>> be picked up when the ruleset is loaded? >>>> >>> >>> Yes, that was my thought. So if you specify in your .eslintrc file >>> something like: >>> >>> { >>> "ians-rules": "default" (not sure what this value should be.) >>> } >>> >>> It would just load the default configuration. >>> >>> Should rulesets be installed locally (per project) or globally (for >>>> all projects)? I can see arguments going both ways. >>>> >>> >>> I think they should be local. I see there being rulesets for various >>> JS frameworks (Backbone, Ember, Angular), which will vary from project to >>> project. I also think by design, ESLint core is meant to contain the most >>> broad rules, therefore custom rulesets will most likely contain very >>> granular, specific (possibly project-specific) rules and that, to me, >>> signals that these rulesets should be local. >>> >>> Should custom rules be grouped in with the regular rules rather than >>>> in a separate area defined by ruleset name? >>>> >>> >>> I'm not opposed to this. I think it's definitely cleaner than >>> separating them, however, you do lose a bit of context around where the >>> rules are coming from. If you prefer this, let's do this. >>> >>> >>>> Would it makes sense to decouple the ruleset configuration of rules >>>> from the loading of rulesets? For instance, maybe we should have a >>>> "rulesets" key that is an array where you can put "rulesets": >>>> ["ians-rules"]. >>>> >>> >>> If we go the direction that you imply in the previous question, then >>> yes. Another thought that has occurred to me is that if we enforce an >>> naming convention for rulesets (i.e. eslint-ruleset-mycoolrules) we can >>> scan the node_modules directory looking for that naming convention and >>> auto-load the rules. Users would then just need to add in the rule keys to >>> their .eslintrc. >>> >>> >>>> These are just off the top of my head, thanks for putting in the work >>>> for this. >>>> >>>> -N >>>> >>>> >>>> >>>> On Mon, Dec 23, 2013 at 2:44 PM, Ian Christian Myers < >>>> [email protected]> wrote: >>>> >>>>> My responses are inline below. Hopefully this clarifies a few things. >>>>> >>>>> >>>>> 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) >>>>> >>>>> >>>>> If you are creating a new project and want to get eslint and a >>>>> custom rule set working you would: >>>>> >>>>> * npm install -g eslint (if you haven’t already done so) >>>>> * npm install eslint-custom-ruleset —save-dev >>>>> * Create your .eslintrc file. (side note: eslint CLI could have a >>>>> command to copy the default eslint.json to .eslintrc OR another yeoman >>>>> generator could do something similar) >>>>> * Add the custom rules to your .eslintrc file under the custom rule >>>>> set’s key, like so: >>>>> >>>>> “rules”: { >>>>> ... >>>>> }, >>>>> “custom-ruleset-name”: { >>>>> “custom-rule”: 2 >>>>> } >>>>> >>>>> >>>>> * 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 not sure I understand this scenario. What I think you’re asking >>>>> is this: I’m creating ian-project, which relies on ilya-project. >>>>> ilya-project uses eslint and a few custom rule sets. Can ian-project use >>>>> ilya-project’s installation of eslint and the custom rule sets? Under the >>>>> current proposal, no. ian-project would need to have to list and install >>>>> its dependencies, and configure eslint and the rules separately. >>>>> >>>>> * 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? >>>>> >>>>> >>>>> If you npm install <custom-ruleset-name> it will install to the >>>>> node_modules directory. Once you’ve added these rules to your .eslintrc >>>>> file, it will be eslint’s responsibility to find and load them from the >>>>> node_modules directory. >>>>> >>>>> 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. >>>>> >>>>> >>>>> I prefer to have all of my rule configurations in one place, but if >>>>> it seems like most people want to have separate configuration files, that >>>>> could fit with this proposal fairly well. >>>>> >>>>> Thanks, >>>>> >>>>> Ilya Volodin >>>>> >>>>> >>>>> Thanks for taking the time to give feedback. >>>>> >>>>> Best, >>>>> >>>>> Ian >>>>> >>>>> >>>>> 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]> >>>>>> 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]> 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]> 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]> 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://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. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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://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. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> 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. >>>>> >>>>> >>>>> -- >>>>> 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. >>> >> >> >> >> -- >> >> ______________________________ >> 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.
