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]<javascript:>
> > 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] <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].
For more options, visit https://groups.google.com/groups/opt_out.
