create eslint-plugin-xstate package
#221
Conversation
|
| "@typescript-eslint/parser": "^5.37.0", | ||
| "concurrently": "6.2.0", | ||
| "esbuild": "^0.14.48", | ||
| "eslint": "^7.26.0", | ||
| "eslint": "^8.0.0", |
There was a problem hiding this comment.
We have the config in .eslintrc.js commented out so updating these doesn't affect anything
| "devDependencies": { | ||
| "@typescript-eslint/parser": "^5.37.0", | ||
| "eslint": "^8.0.0", | ||
| "typescript": "^4.3.5" | ||
| }, | ||
| "peerDependencies": { | ||
| "@typescript-eslint/parser": "^5.0.0", | ||
| "eslint": "^6.0.0 || ^7.0.0 || ^8.0.0", | ||
| "typescript": "*" | ||
| }, | ||
| "peerDependenciesMeta": { | ||
| "typescript": { | ||
| "optional": true | ||
| } | ||
| } |
There was a problem hiding this comment.
I'm not entirely sure these dependencies are correct if we end up publishing this package. I somewhat copied the dependencies setup from @typescript-eslint/eslint-plugin, but they also don't have any of these as devDependencies which yarn whined about 🤷
| ruleTester.run("avoid-context-spread", rule, { | ||
| valid: [ | ||
| { | ||
| code: outdent` |
There was a problem hiding this comment.
Using outdent allows the code blocks to be displayed correctly in test output. Not sure if there's a better way to handle that but without it, the indentation was a mess.
|
Would love to have a discussion on My ultimate goal in playing with this stuff was to use it as the basis for a v5 codemod that automatically migrates codebases (as much as possible, anyway). Perhaps it'd be better to just start with that, or figure out ways to implement this type of stuff through the extension instead of |
with-heart
force-pushed
the
eslint-plugin-and-config
branch
from
f4a3066
to
2dfb6d7
Compare
I would say |
|
Someone already wrote an |
Hi all! This draft PR contains the start of the
eslint-plugin-xstatepackage and will eventually resolve #216.Currently this PR contains implementations for a few rules:
avoid-context-spreadno-condno-emitted-fromno-factory-context-argrequire-object-contextrequire-parameterized-actions-paramsrequire-parameterized-guards-paramsHaving briefly talked to @Andarist about it, I'm not entirely sure an
eslintplugin/config makes sense for his vision of XState tooling. It's possible that these rules (and others listed in the issue) would be more useful if implemented as part of the VSCode extension rather than ineslint.At the very least, this has been a fun exploration of custom
eslintrules for me and might give us a sense of the type of logic we'd need to implement similar functionality in the extension.