feat: Rule API updates for v9 #471
Conversation
✅ Deploy Preview for hi-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for new-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for es-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for ja-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for de-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for pt-br-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for fr-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for zh-hans-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
src/content/blog/2023-09-26-preparing-custom-rules-eslint-v9.md
Outdated
Show resolved
Hide resolved
src/content/blog/2023-09-26-preparing-custom-rules-eslint-v9.md
Outdated
Show resolved
Hide resolved
src/content/blog/2023-09-26-preparing-custom-rules-eslint-v9.md
Outdated
Show resolved
Hide resolved
src/content/blog/2023-09-26-preparing-custom-rules-eslint-v9.md
Outdated
Show resolved
Hide resolved
src/content/blog/2023-09-26-preparing-custom-rules-eslint-v9.md
Outdated
Show resolved
Hide resolved
| |`context.getSourceLines()`|`sourceCode.getLines()`| | ||
| |`context.getAllComments()`|`sourceCode.getAllComments()`| | ||
| |`context.getNodeByRangeIndex()`|`sourceCode.getNodeByRangeIndex()`| | ||
| |`context.getComments()`|`sourceCode.getComments()`| |
There was a problem hiding this comment.
sourceCode.getComments() is actually going to be removed in v9: eslint/eslint#14744.
sourceCode.getCommentsBefore(), sourceCode.getCommentsAfter(), and sourceCode.getCommentsInside() should be used instead.
src/content/blog/2023-09-26-preparing-custom-rules-eslint-v9.md
Outdated
Show resolved
Hide resolved
|
|
||
| Additionally, the `context.parserOptions` and `context.parserPath` properties are deprecated and will be removed in v9.0.0. There is a new `context.languageOptions` property that allows rules to access similar data as `context.parserOptions`. In general, though, rules should not depend on information either in `context.parserOptions` or `context.languageOptions` to determine how they should behave; this information is primarily for debugging purposes. | ||
|
|
||
| The `context.parserPath` property was intended to allow rules to retrieve an instance of the parser that ESLint is using via `require()`. However, the new flat config system does not know the location of the parser module to load, so we are unable to provide this data. Further, because the JavaScript ecosystem is moving to ESM, any value returned from this property will not work with `import()`. This property was added early on in ESLint's life and we generally recommend that rules not try to further parse JavaScript code inside of them. |
There was a problem hiding this comment.
Shall we mention that context.languageOptions.parser can be used instead?
There was a problem hiding this comment.
I went back and forth on this, but I'll add it. For non-JS languages this won't work, though because the parser (likely) won't be customizable and therefore not appear in languageOptions.
| }; | ||
| ``` | ||
|
|
||
| ## `context` properties being removed |
There was a problem hiding this comment.
In eslint/eslint#13481, removing context.parserPath and context.parserOptions is in Phase 5: Remove eslintrc, which would be in eslint v10, not v9?
|
|
||
| ## `context` properties being removed | ||
|
|
||
| Additionally, the `context.parserOptions` and `context.parserPath` properties are deprecated and will be removed in v9.0.0. There is a new `context.languageOptions` property that allows rules to access similar data as `context.parserOptions`. In general, though, rules should not depend on information either in `context.parserOptions` or `context.languageOptions` to determine how they should behave; this information is primarily for debugging purposes. |
There was a problem hiding this comment.
I'm not sure if using context.languageOptions should generally be discouraged. We're using it in multiple core rules:
https://github.com/search?q=repo%3Aeslint%2Feslint+context.languageOptions&type=code
parserOptions.ecmaVersion was unreliable but languageOptions.ecmaVersion as an option of ESLint itself rather than a parser-specific feature fixes those issues.
There was a problem hiding this comment.
I still feel like it's a bit of a bad practice as things like ecmaVersion aren't guaranteed to mean anything, especially with so many people using custom parsers.
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
|
I'm planning on merging this tomorrow, so any final comments appreciated. |
src/content/blog/2023-09-26-preparing-custom-rules-eslint-v9.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Amaresh S M <amareshsm13@gmail.com>
Prerequisites checklist
What is the purpose of this pull request?
What changes did you make? (Give an overview)
Wrote a blog post about the deprecated properties and methods rules need to be aware of.
Related Issues
Is there anything you'd like reviewers to focus on?
Check spelling and grammar please :)