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 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 -- 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.
