Add support for a plugin system.

In order to allow customization that is more organization specific (where a given rule may not be applicable to a broad audience) I would like to add support for a plugin system to ember-template-lint.

More concretely, I propose that:

• We add a new plugins key to the .template-lintrc.js file. It would be an array that would allow entries to be either of the following:

  • An object with the following properties (both are optional):
    • rules - An object where the keys are the rule names and the values are the rules themselves. This is roughly the same format as lib/rules/index.js ( { 'rule-name': require('./some-rule-path-whatever-lol') }).
    • configurations - An object where the keys are the names and the values are the actual config to be used for each.
  • A plain string, that is resolved (relative to the config files path) and then required. When required it must have the same format as the object mentioned above.

• We expand extends to allow both a string and an array. The array contents would only allow strings and each entry must resolve to a known config.

• Expose public API’s for our custom testing harness (still needs more research).

• In ember-cli-template-lint we create a blueprint for creating rules in an ember-cli project/addon (with tests).

---

Example config:

module.exports = {
  plugins: [
    // this would work (we would require and expect it to export a similar structure to the below object):
    'something-something-npm-package',

    // and this (for in project rules):
    {
      rules: [
        'disallow-inline-components': require('./lib/template-lint-rules/disallow-inline-components')
      ],
      configurations: [
        'no-inline': {
            rules: {
              'disallow-inline-components': true
            }
        }
      ]
    },
  ],

  extends: [
    'recommended',
    'no-inline'
  ],

  rules: {
    'bare-strings': true
  }
}

---

Open questions:

• Should we add a name property to the plugin object and make it required? (might be nice for warnings and deprecations down the line)
• Somewhat related to name, should we prefix config names with the plugin name? (i.e. "ember-template-lint-plugin-a11y:recommended"? (I’m leaning towards no, but it does make it easier to see where each config is coming from…)
• Should we allow a plugin config to extend another config? (seems like it should be supported/allowed to me…)

---

Initial proposal - 2016-11-10

• We add a new plugins key to the .template-lintrc.js file. It would be an array that would allow entries to be either of the following:

  • An object in the same format as lib/rules/index.js ( { 'rule-name': require('./some-rule-path-whatever-lol') }).
  • A plain string, that is resolved (relative to the config files path) and then required. When required it must have the same format as the object mentioned above.

• We expand extends to allow both a string and an array. The array contents would be roughly the same allowed values as plugins (mentioned above).

• Expose public API’s for our custom testing harness (still needs more research).

• In ember-cli-template-lint we create a blueprint for creating rules in an ember-cli project/addon (with tests).

---

Example config:

module.exports = {
  plugins: [
    // this would work (we would require and expect it to export a similar structure to the below object):
    'something-something-npm-package',

    // and this (for in project rules):
    {
      'custom-rule-name-here': require('./lib/template-lint-rules/custom-rule-name-here')
    },
  ],

  extends: [
    'recommended',
    'something-something-npm-package/config'
  ],

  rules: {
    'bare-strings': true
  }
}

[rwjblue]

The main thrust of this has landed (thanks to @ppcano!). I’m going to close this issue (since its basically done) and open more targeted issues for the remaining pieces.

[ppcano]

@rwjblue

Please, may you confirm the open questions.

I say YES to all.

Should we add a name property to the plugin object and make it required? Somewhat related to name, should we prefix config names with the plugin name?

Prefixing config name prevents config name collision of different plugins.

module.exports = {
  plugins: [
    // this would work (we would require and expect it to export a similar structure to the below object):
    'something-something-npm-package',

    // and this (for in project rules):
    {
      name: 'inline-plugin',
      rules: {
        'disallow-inline-components': require('./lib/template-lint-rules/disallow-inline-components')
      },
      configurations: {
        'no-inline': {
            rules: {
              'disallow-inline-components': true
            }
        }
      }
    },
  ],

  extends: [
    'recommended',
    'inline-plugin:no-inline'
  ],

  rules: {
    'bare-strings': true
  }
}