|
| 1 | +- Start Date: 2019-07-16 |
| 2 | +- RFC PR: (leave this empty, to be filled in later) |
| 3 | +- Authors: Toru Nagashima ([@mysticatea](https://github.com/mysticatea)) |
| 4 | + |
| 5 | +# RuleTester supports processor |
| 6 | + |
| 7 | +## Summary |
| 8 | + |
| 9 | +This RFC makes `RuleTester` class supporting `processor` option. |
| 10 | + |
| 11 | +## Motivation |
| 12 | + |
| 13 | +Currently, we cannot test rules with processors. This is inconvenient for plugin rules which depend on processors. For example, [vue/comment-directive](https://github.com/vuejs/eslint-plugin-vue/blob/6751ff47b4ecd722bc2e2436ce6b34a510f92b07/tests/lib/rules/comment-directive.js) rule could not use `RuleTester` to test. |
| 14 | + |
| 15 | +## Detailed Design |
| 16 | + |
| 17 | +To add `processor` option and `processorOptions` (see #29) to test cases. |
| 18 | + |
| 19 | +```js |
| 20 | +const { RuleTester } = require("eslint") |
| 21 | +const rule = require("../../../lib/rules/example-rule") |
| 22 | +const exampleProcessor = require("../../../lib/processors/example-processor") |
| 23 | + |
| 24 | +const tester = new RuleTester() |
| 25 | + |
| 26 | +tester.run("example-rule", rule, { |
| 27 | + valid: [ |
| 28 | + { |
| 29 | + code: ` |
| 30 | + <script> |
| 31 | + console.log("Hello") |
| 32 | + </script> |
| 33 | + `, |
| 34 | + processor: exampleProcessor, |
| 35 | + processorOptions: {}, |
| 36 | + }, |
| 37 | + ], |
| 38 | + invalid: [], |
| 39 | +}) |
| 40 | +``` |
| 41 | + |
| 42 | +### § `processor` option |
| 43 | + |
| 44 | +This is a definition object of a processor that the "[Processors in Plugins](https://eslint.org/docs/developer-guide/working-with-plugins#processors-in-plugins)" section describes. |
| 45 | + |
| 46 | +If this option was given, the tester applies the given processor to test code. |
| 47 | + |
| 48 | +If the given processor didn't has `supportsAutofix:true`, the tester doesn't do autofix. Then if the test case had `output` option (except `null`) then the test case will fail. |
| 49 | + |
| 50 | +### § `processorOptions` option |
| 51 | + |
| 52 | +RFC #29 defines the `processorOptions`. |
| 53 | + |
| 54 | +If this option was given along with `processor` option, it will be given to the processor. |
| 55 | + |
| 56 | +## Documentation |
| 57 | + |
| 58 | +The [RuleTester](https://eslint.org/docs/developer-guide/nodejs-api#ruletester) section should describe the new `processor` and `processorOptions` properties. |
| 59 | + |
| 60 | +## Drawbacks |
| 61 | + |
| 62 | +It's a pretty rare case of a rule depends on the processor's behavior. I'm not sure if this feature is needed. |
| 63 | + |
| 64 | +## Backwards Compatibility Analysis |
| 65 | + |
| 66 | +There are no concerns about breaking changes. |
| 67 | + |
| 68 | +## Related Discussions |
| 69 | + |
| 70 | +- https://github.com/eslint/rfcs/pull/25#issuecomment-499877621 |
0 commit comments