Unmatched rule names of scoped plugins.

[mysticatea]

What version of ESLint are you using?

• v2.11.1

What parser (default, Babel-ESLint, etc.) are you using?

• default.

Please show your full configuration:

• I use @mysticatea/eslint-plugin-test plugin here.

{
    "plugins": [
        "@mysticatea/test"
    ],
    "rules": {
        "@mysticatea/test/test": "error"
    }
}

@mysticatea/test/test rule is:

    return {
        "Program": function(node) {
            context.report({
                node: node,
                message: "This is a test."
            })
        }
    }

What did you do? Please include the actual source code causing the issue.

• eslint test.js

What did you expect to happen?

test.js
  1:1  error  This is a test  @mysticatea/test/test

✖ 1 problem (1 error, 0 warnings)

What actually happened? Please include the actual, raw output from ESLint.

test.js
  1:1  error  Definition for rule '@mysticatea/test/test' was not found  @mysticatea/test/test

✖ 1 problem (1 error, 0 warnings)

---

I think we should support @mysticatea/test/test form's rule specifier.
Thought?

[nzakas]

@mysticatea I'm not sure what you're suggesting here. Can you explain some more?

[mysticatea]

{
    "plugins": [
        "@mysticatea/test"
    ],
    "rules": {
        "@mysticatea/test/test": "error"
    }
}

I expected this "@mysticatea/test/test" to be the test rule of @mysticatea/eslint-plugin-test plugin.
But actually, ESLint throws "Rule not found" error.
"@mysticatea/eslint-plugin-test/test" throws "Rule not found" error as same.

On the other hand, "test/test" works unexpectedly for the test rule of @mysticatea/eslint-plugin-test plugin.

[mysticatea]

My suggestion is:

• "test/test" should pointer the test rule of eslint-plugin-test plugin.
• "@mysticatea/test/test" should pointer the test rule of @mysticatea/eslint-plugin-test plugin.

So this may be a breaking change.

[nzakas]

Oh wow, that's really bad. I agree with your suggestion. This is definitely breaking. We should try to get some feedback from the community to see how many people would be affected.

[pmcelhaney]

I think there are two components here.

• Non-breaking change: Make "@mystictea/test/test" find the rule.
• Breaking change: Make "test/test" not find the rule.

You could probably go ahead and implement the non-breaking change and open another issue for the breaking change.

[platinumazure]

What happens when there's an unscoped eslint-plugin-test with test rule (proper name "test/test") and a scoped eslint-plugin-test with test rule (proper name "@mysticatea/test/test", but may be found with "test/test") at the same time?

[scottnonnenberg]

I use scoped plugins and the need to drop the scope for the rule name was initially confusing. It would help people new to scoped stuff to make the rule names a bit more predictable. Maybe support both for a while in ESLint 3, then 4x could require the scope name?

[nzakas]

@pmcelhaney that's a good point, we can definitely add the correct scoped name resolution without removing the incorrect behavior, though that means naming clashes are still possible.

@platinumazure the plugin that was loaded last wins in that scenario. That's why this is a particularly nasty bug.

@scottnonnenberg Yes, this is a bug and not intentional. It's very confusing as it is.

[nzakas]

TSC Summary: We've uncovered a bug where scoped npm packages (such as @foo/eslint-plugin-bar) cannot have their rules configured using @foo/bar/rule and instead must use bar/rule. This is bad because it clashes with unscoped npm packages such as eslint-plugin-bar, leaving us in a situation where you cannot reliably use both plugins at the same time because the rules are occupying the same namespace. To fix this behavior would be a breaking change.

TSC Questions:

1. Is this important enough to introduce a breaking change now?
2. Should we do an incremental approach where we add the ability to reference scoped packages directly for a while and still allow referencing without the scope? Then we could remove the buggy behavior in a later major release.