|
1 | 1 | # es-spec-validator |
2 | 2 |
|
3 | 3 | An [ESLint](https://eslint.org/) plugin that uses [typescript-eslint](https://typescript-eslint.io/) to validate the Elasticsearch specification against a set of custom rules. |
4 | | -It is configured [in the specification directory](../specification/eslint.config.mjs). |
| 4 | +It is configured [in the specification directory](../specification/eslint.config.js). |
5 | 5 |
|
6 | 6 | ## Rules |
7 | 7 |
|
8 | 8 | | Name | Description | |
9 | 9 | | - | - | |
10 | 10 | | `single-key-dictionary-key-is-string` | `SingleKeyDictionary` keys must be strings | |
11 | 11 |
|
12 | | -## Writing rules |
| 12 | +## Usage |
13 | 13 |
|
14 | | -Each rule should be written in a separate JavaScript file (e.g. `single-key-dictionary-key-is-string.mjs`) following the format of a custom rule [as defined by the typescript-eslint docs](https://typescript-eslint.io/developers/custom-rules). |
15 | | -Within a rule's `create` function, return an object whose keys are the names of [AST node types](https://typescript-eslint.io/packages/typescript-estree/ast-spec). |
| 14 | +Prerequisites: [Node.js](https://nodejs.org) and [`npm`](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) must be installed locally. |
16 | 15 |
|
17 | | -If a rule needs to report a problem, it should call `context.report()` with the appropriate arguments. |
| 16 | +1. Enter the `specification/` directory: `cd specification/` |
| 17 | +1. Install dependencies (first time only): `npm install` |
| 18 | +1. Run the linter on the specification project: `npm run lint` |
| 19 | + |
| 20 | +Or, from the repository's root directory, run `make setup && make validate`. |
| 21 | +This will run the linter, along with several other validations. |
| 22 | + |
| 23 | +If the linter finds problems in the spec code, it will print them out. |
| 24 | +If all is well, the output will be minimal, and the process will exit cleanly. |
| 25 | + |
| 26 | +ESLint also maintains [integrations](https://eslint.org/docs/latest/use/integrations#editors) for most common code editors to provide instant inline feedback as you modify files. |
| 27 | + |
| 28 | +## Writing new linter rules |
| 29 | + |
| 30 | +Each rule should be written in a separate JavaScript file (e.g. `single-key-dictionary-key-is-string.js`) following the format of a custom rule [as defined by the typescript-eslint docs](https://typescript-eslint.io/developers/custom-rules). |
| 31 | +Within a rule's `create` function, return an object whose keys are the names of [AST node types](https://typescript-eslint.io/packages/typescript-estree/ast-spec) and whose values are functions that validate that node type. |
| 32 | +To report a problem in a validation function, it should call `context.report()` with the appropriate arguments. |
18 | 33 |
|
19 | 34 | To get a familiar the different node types possible within a TypeScript AST, paste some code into [an AST viewer](https://ts-ast-viewer.com/) and explore the resulting visual tree. |
20 | 35 |
|
21 | | -To add your rule to the spec validator ESLint plugin, import it into [the plugin file](./eslint-plugin-es-spec.mjs) and add it to the `rules` object with an appropriate key. |
| 36 | +To add your rule to the spec validator ESLint plugin, import it into [the plugin file](./eslint-plugin-es-spec.js) and add it to the `rules` object with an appropriate key. |
| 37 | + |
| 38 | +### ESM format |
| 39 | + |
| 40 | +The validator project is written in standard JavaScript rather than TypeScript, and uses the new [ESM](https://nodejs.org/api/esm.html) module format for managing module imports and exports. |
| 41 | +Files should use the normal `.js` file extension, and the `import` format is almost identical to TypeScript's, except that ESM requires you to include the file extension in the import statement. Example: |
| 42 | + |
| 43 | +```js |
| 44 | +import myRule from './rules/my-rule.js' // not ./rules/my-rule |
| 45 | +``` |
0 commit comments