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.
