You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can also create custom processors that tell ESLint how to process files other than JavaScript.
11
+
12
+
## Custom Processor Specification
13
+
14
+
In order to create a processor, the object that is exported from your module has to conform to the following interface:
15
+
16
+
```js
17
+
module.exports= {
18
+
processors: {
19
+
"processor-name": {
20
+
// takes text of the file and filename
21
+
preprocess:function(text, filename) {
22
+
// here, you can strip out any non-JS content
23
+
// and split into multiple strings to lint
24
+
25
+
return [ // return an array of code blocks to lint
26
+
{ text: code1, filename:"0.js" },
27
+
{ text: code2, filename:"1.js" },
28
+
];
29
+
},
30
+
31
+
// takes a Message[][] and filename
32
+
postprocess:function(messages, filename) {
33
+
// `messages` argument contains two-dimensional array of Message objects
34
+
// where each top-level array item contains array of lint messages related
35
+
// to the text that was returned in array from preprocess() method
36
+
37
+
// you need to return a one-dimensional array of the messages you want to keep
38
+
return [].concat(...messages);
39
+
},
40
+
41
+
supportsAutofix:true// (optional, defaults to false)
42
+
}
43
+
}
44
+
};
45
+
```
46
+
47
+
**The `preprocess` method** takes the file contents and filename as arguments, and returns an array of code blocks to lint. The code blocks will be linted separately but still be registered to the filename.
48
+
49
+
A code block has two properties `text` and `filename`; the `text` property is the content of the block and the `filename` property is the name of the block. Name of the block can be anything, but should include the file extension, that would tell the linter how to process the current block. The linter will check [`--ext` CLI option](../use/command-line-interface#--ext) to see if the current block should be linted, and resolve `overrides` configs to check how to process the current block.
50
+
51
+
It's up to the plugin to decide if it needs to return just one part, or multiple pieces. For example in the case of processing `.html` files, you might want to return just one item in the array by combining all scripts, but for `.md` file where each JavaScript block might be independent, you can return multiple items.
52
+
53
+
**The `postprocess` method** takes a two-dimensional array of arrays of lint messages and the filename. Each item in the input array corresponds to the part that was returned from the `preprocess` method. The `postprocess` method must adjust the locations of all errors to correspond to locations in the original, unprocessed code, and aggregate them into a single flat array and return it.
54
+
55
+
Reported problems have the following location information:
56
+
57
+
```typescript
58
+
{
59
+
line: number,
60
+
column: number,
61
+
62
+
endLine?:number,
63
+
endColumn?:number
64
+
}
65
+
```
66
+
67
+
By default, ESLint will not perform autofixes when a processor is used, even when the `--fix` flag is enabled on the command line. To allow ESLint to autofix code when using your processor, you should take the following additional steps:
68
+
69
+
1. Update the `postprocess` method to additionally transform the `fix` property of reported problems. All autofixable problems will have a `fix` property, which is an object with the following schema:
70
+
71
+
```js
72
+
{
73
+
range: [number, number],
74
+
text: string
75
+
}
76
+
```
77
+
78
+
The `range` property contains two indexes in the code, referring to the start and end location of a contiguous section of text that will be replaced. The`text` property refers to the text that will replace the given range.
79
+
80
+
In the initial list of problems, the `fix` property will refer to a fix in the processed JavaScript. The`postprocess` method should transform the object to refer to a fix in the original, unprocessed file.
81
+
82
+
2. Add a `supportsAutofix: true` property to the processor.
83
+
84
+
You can have both rules and processors in a single plugin. You can also have multiple processors in one plugin.
85
+
To support multiple extensions, add each one to the `processors` element and point them to the same object.
86
+
87
+
## Specifying Processor in Config Files
88
+
89
+
To use a processor, add its ID to a `processor` section in the config file. ProcessorID is a concatenated string of plugin name and processor name with a slash as a separator. This can also be added to a `overrides` section of the config, to specify which processors should handle which files.
90
+
91
+
For example:
92
+
93
+
```yml
94
+
plugins:
95
+
- a-plugin
96
+
overrides:
97
+
- files: "*.md"
98
+
processor: a-plugin/markdown
99
+
```
100
+
101
+
See [Specify a Processor](../use/configure/plugins#specify-a-processor) in the Plugin Configuration documentation for more details.
102
+
103
+
## File Extension-named Processor
104
+
105
+
If a processor name starts with`.`, ESLint handles the processor as a **file extension-named processor** especially and applies the processor to the kind of files automatically. People don't need to specify the file extension-named processors in their config files.
106
+
107
+
For example:
108
+
109
+
```js
110
+
module.exports = {
111
+
processors: {
112
+
// This processor will be applied to `*.md` files automatically.
113
+
// Also, people can use this processor as "plugin-id/.md" explicitly.
Copy file name to clipboardExpand all lines: docs/src/extend/plugins.md
+7-96Lines changed: 7 additions & 96 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -57,109 +57,20 @@ Plugin environments can define the following objects:
57
57
58
58
### Processors in Plugins
59
59
60
-
You can also create plugins that would tell ESLint how to process files other than JavaScript. In order to create a processor, the object that is exported from your module has to conform to the following interface:
61
-
62
-
```js
63
-
module.exports= {
64
-
processors: {
65
-
"processor-name": {
66
-
// takes text of the file and filename
67
-
preprocess:function(text, filename) {
68
-
// here, you can strip out any non-JS content
69
-
// and split into multiple strings to lint
70
-
71
-
return [ // return an array of code blocks to lint
72
-
{ text: code1, filename:"0.js" },
73
-
{ text: code2, filename:"1.js" },
74
-
];
75
-
},
76
-
77
-
// takes a Message[][] and filename
78
-
postprocess:function(messages, filename) {
79
-
// `messages` argument contains two-dimensional array of Message objects
80
-
// where each top-level array item contains array of lint messages related
81
-
// to the text that was returned in array from preprocess() method
82
-
83
-
// you need to return a one-dimensional array of the messages you want to keep
84
-
return [].concat(...messages);
85
-
},
86
-
87
-
supportsAutofix:true// (optional, defaults to false)
88
-
}
89
-
}
90
-
};
91
-
```
92
-
93
-
**The `preprocess` method** takes the file contents and filename as arguments, and returns an array of code blocks to lint. The code blocks will be linted separately but still be registered to the filename.
94
-
95
-
A code block has two properties `text` and `filename`; the `text` property is the content of the block and the `filename` property is the name of the block. Name of the block can be anything, but should include the file extension, that would tell the linter how to process the current block. The linter will check [`--ext` CLI option](../use/command-line-interface#--ext) to see if the current block should be linted, and resolve `overrides` configs to check how to process the current block.
96
-
97
-
It's up to the plugin to decide if it needs to return just one part, or multiple pieces. For example in the case of processing `.html` files, you might want to return just one item in the array by combining all scripts, but for `.md` file where each JavaScript block might be independent, you can return multiple items.
98
-
99
-
**The `postprocess` method** takes a two-dimensional array of arrays of lint messages and the filename. Each item in the input array corresponds to the part that was returned from the `preprocess` method. The `postprocess` method must adjust the locations of all errors to correspond to locations in the original, unprocessed code, and aggregate them into a single flat array and return it.
100
-
101
-
Reported problems have the following location information:
102
-
103
-
```typescript
104
-
{
105
-
line: number,
106
-
column: number,
107
-
108
-
endLine?:number,
109
-
endColumn?:number
110
-
}
111
-
```
112
-
113
-
By default, ESLint will not perform autofixes when a processor is used, even when the `--fix` flag is enabled on the command line. To allow ESLint to autofix code when using your processor, you should take the following additional steps:
114
-
115
-
1. Update the `postprocess` method to additionally transform the `fix` property of reported problems. All autofixable problems will have a `fix` property, which is an object with the following schema:
116
-
117
-
```js
118
-
{
119
-
range: [number, number],
120
-
text: string
121
-
}
122
-
```
123
-
124
-
The `range` property contains two indexes in the code, referring to the start and end location of a contiguous section of text that will be replaced. The`text` property refers to the text that will replace the given range.
125
-
126
-
In the initial list of problems, the `fix` property will refer to a fix in the processed JavaScript. The`postprocess` method should transform the object to refer to a fix in the original, unprocessed file.
127
-
128
-
2. Add a `supportsAutofix: true` property to the processor.
129
-
130
-
You can have both rules and processors in a single plugin. You can also have multiple processors in one plugin.
131
-
To support multiple extensions, add each one to the `processors` element and point them to the same object.
132
-
133
-
#### Specifying Processor in Config Files
134
-
135
-
To use a processor, add its ID to a `processor` section in the config file. ProcessorID is a concatenated string of plugin name and processor name with a slash as a separator. This can also be added to a `overrides` section of the config, to specify which processors should handle which files.
136
-
137
-
For example:
138
-
139
-
```yml
140
-
plugins:
141
-
- a-plugin
142
-
overrides:
143
-
- files: "*.md"
144
-
processor: a-plugin/markdown
145
-
```
146
-
147
-
See [Specifying Processor](../use/configure/plugins#specify-a-processor) for details.
148
-
149
-
#### File Extension-named Processor
150
-
151
-
If a processor name starts with`.`, ESLint handles the processor as a **file extension-named processor** especially and applies the processor to the kind of files automatically. People don't need to specify the file extension-named processors in their config files.
152
-
153
-
For example:
60
+
You can add processors to plugins by including the processor functions in the `processors` key. For more information on defining custom processors, refer to [Custom Processors](custom-processors).
154
61
155
62
```js
156
63
module.exports= {
157
64
processors: {
158
65
// This processor will be applied to `*.md` files automatically.
159
-
// Also, people can use this processor as "plugin-id/.md" explicitly.
Copy file name to clipboardExpand all lines: docs/src/integrate/nodejs-api.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ eleventyNavigation:
4
4
key: node.js api
5
5
parent: extend eslint
6
6
title: Node.js API Reference
7
-
order: 6
7
+
order: 7
8
8
---
9
9
10
10
While ESLint is designed to be run on the command line, it's possible to use ESLint programmatically through the Node.js API. The purpose of the Node.js API is to allow plugin and tool authors to use the ESLint functionality directly, without going through the command line interface.
0 commit comments