Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve handling of plugins with only one rule #11469

Closed
getify opened this Issue Mar 3, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@getify
Copy link

getify commented Mar 3, 2019

The version of ESLint you are using.

5.15.0

The problem you want to solve.

I would like to be able to publish (scoped) plugins that only have one rule, and have the plugin name basically stand-in as the rule name, without the verbosity of duplicating plugin-name/rule-name.

IOW, if there's only one rule in my plugin, I would want (for marketing purposes, at least!) to name the plugin what I would actually call the rule. But it looks weird to have to do "my-cool-rule/my-cool-rule".

Your take on the correct solution to problem.

It would be nice if a plugin could expose itself like eslint's built-in rules do, which is:

module.exports = {
   meta: { .. },
   create(context) { .. }
};

Alternately, if that can't work, something like this would be fine:

module.exports = {
   rule: {
      meta: { .. },
      create(context) { .. }
   }
};

Even this would be OK (although a little weird semantically):

module.exports = {
   rules: {
      meta: { .. },
      create(context) { .. }
   }
};

If ESLint (the CLI, for example) loads a plugin like that, it can assume only one rule, and therefore assume the name of the plugin is usable as the name of the rule.

So, if I publish a plugin called @getify/eslint-plugin-myfoobar, and load that plugin by name @getify/myfoobar, then I could configure the rule like: "@getify/myfoobar": "error".

Are you willing to submit a pull request to implement this change?

I would be happy to do so, if the change is approved first.

@not-an-aardvark

This comment has been minimized.

Copy link
Member

not-an-aardvark commented Mar 3, 2019

Hi, thanks for the proposal.

I think my main concern here is naming ambiguity when a user refers to a rule in a config file. In a config file like this:

module.exports = {
    plugins: [
        "@getify/myfoobar", // resolves to @getify/eslint-plugin-myfoobar
        "@getify" // resolves to @getify/eslint-plugin
    ],
    rules: {
        "@getify/myfoobar": "error"
    }
};

Currently, the reference to @getify/myfoobar in the rules section will always refer to a rule called myfoobar in the plugin @getify/eslint-plugin. If we made this change, then it would be ambiguous whether the reference refers to the myfoobar rule from @getify/eslint-plugin, or the single rule exported from @getify/eslint-plugin-myfoobar.

I agree that duplicating rule names like my-cool-rule/my-cool-rule doesn't seem ideal, but personally I'm not sure it's worth increasing the complexity of how rule names are resolved just to avoid the one-time cost of typing my-cool-rule twice.

@not-an-aardvark not-an-aardvark added evaluating and removed triage labels Mar 3, 2019

@getify

This comment has been minimized.

Copy link
Author

getify commented Mar 3, 2019

To disambiguate, would it be possible to have a trailing token like "/" or "/." or even "//" to indicate the intent to reference and configure a rule of the same name as the plugin? Additionally, that convenience "magic" could/would only kick in if there is indeed a rule that would match the duplicated "myfoobar/myfoobar", otherwise no magic.

@not-an-aardvark

This comment has been minimized.

Copy link
Member

not-an-aardvark commented Mar 6, 2019

I think it would be possible to have a way to disambiguate, I'm just not convinced it's worth adding that complexity in order to create what seems to be a very small value-add. If we need to enhance the syntax of how rules are resolved in the future, having more complexity here will make it harder to create new designs.

@getify

This comment has been minimized.

Copy link
Author

getify commented Mar 10, 2019

It feels strange that ESLint supports a "single rule" file format for core rules, but not for plugins. In fact, the public documentation on the "rules format" was what had me off-track (not getting my plugin to work) for at least 2 days of frustration -- why document that format as if you want people to write it, when in fact you don't want them to write it!? It seems like for consistency and simplicity, ESLint would benefit from some official support for single-rule plugins other than the jankiness of having to repeat the full name twice.

That said, since it seems like there's enough resistance to it, I'll withdraw my request.

@getify getify closed this Mar 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.