Allow plugins to be passed in directly

[calebeby]

The version of ESLint you are using.
v5.0.1

The problem you want to solve.
I want sharable configs to be able to list their plugins as dependencies

Your take on the correct solution to problem.
I think that sharable configs should not have to list their plugins as peerDependencies. This behavior does not make sense, because it makes it the responsibility of the user to install and update each of the plugins.

Would you accept a PR that implements this behavior?

#3458 (comment)

[not-an-aardvark]

Hi, thanks for creating an issue. Unfortunately, the solution in #3458 (comment) isn't workable because the user needs to be able to configure the rules in a plugin, which requires the plugin to have a unique name . I'm in agreement with you that the current behavior is not ideal, but there is a significant amount of design work needed to create a better mechanism. No complete, workable solutions to this problem have been proposed so far. (You might also be interested in reading #10125 and the discussion towards the bottom of #3458. I've been working on a draft proposal to solve this issue here, although it's still far from complete.)

[calebeby]

Could an object be passed in?

plugins: [
  {
    name: 'react',
    plugin: require('eslint-plugin-react')
  }
]

[not-an-aardvark]

The problem is that there could be two independent shareable configs which have dependencies on two separate plugins that both happen to be called react (or they depend on two different versions of a plugin called react). If the end user depended on those two shareable configs and also configured a rule like react/some-rule in their top-level config, the end user's config would be ambiguous because it wouldn't be clear which react plugin they were referring to. Since the configurations for a given rule might be incompatible across different versions of a plugin, this could make it impossible to set the configuration for a particular rule or to override a configuration which was set by a shareable config. This would be an unacceptably poor user experience.

Another way to state the problem is that ESLint's mechanism for naming rules in a config file (plugin-name/rule-name) is fundamentally unable to disambiguate two plugins that have the same name. Currently, there are no naming conflicts because all plugins are loaded from the location of the eslint package, so plugins effectively live in a global namespace. If plugins could be loaded as dependencies of shareable configs, then naming conflicts would start to become a problem. As a result, we need to be able to support having two plugins with the same name before we can support having plugins as dependencies of configs.

Since the problem stems from a limitation of ESLint's naming scheme, I think the most straightforward solution to the problem would involve changing the way that rules are named in a config file. For example, one way to solve it would be to have hierarchical naming for rules, where rules would be configured with something that looks like a path. (In other words, a user could refer to a rule like eslint-config-foo/react/some-rule for the version of eslint-plugin-react used by eslint-config-foo, and this would be a different rule than eslint-config-bar/react/some-rule, which would refer to the version of eslint-plugin-react used by eslint-config-bar.)

Unfortunately, there are a lot of complications and edge cases that need to be handled (e.g. if configs extend each other with relative paths), and any new config format would need to be backwards-compatible with existing configs (at least in the vast majority of cases). This is why it's a difficult design problem, and why #3458 has been open for almost three years -- no one has proposed a complete design yet that solves the issue.

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.