Whether to consider writing an eslint plugin？

[lzm0x219]

It seems that there is no eslint plugin available.

[ryansolid]

I think people would find it valuable. I've just no experience here. I only recently used ESLint for the first time. I worked for years in a CoffeeScript env that by the time I got out of it people were more on Prettier + TS, skipping ESLint.

[lzm0x219]

I am used to using prettier + eslint. I haven't written eslint plug-ins, I can look into it if I have time.

[joshwilsonvu]

New to the project but I'd love to help write an ESLint plugin for it. TypeScript is great but ESLint is critical for a whole different class of issues, like little library gotchas that are hard to remember. For instance:

Important: The first argument needs to be a function. Otherwise we can't properly track and schedule the reactive system. This simple omission will cause your Effects not to run.

Something like this should be caught in the IDE before runtime, and that could potentially save someone a lot of debugging time. Development runtime warnings are okay, but they can be easily ignored. ESLint is so ubiquitous that lot of organizations require lint diagnostics to be free of errors in their CI/CD. That encourages fixing issues like this right away and keeping the codebase quality high. I'd go so far as to say there needs to be an ESLint plugin before we can have a Next.js-like experience, especially with many new devs picking it up after the 1.0 release.

I think a good way to get started would be to collect a list of possible gotchas. Off the top of my head:

• first argument of render() should be a function returning an element, not an element
• don't destructure props
• don't try to track a signal asynchronously
• signal getters should be called instead of passed directly (value={value()}, not value={value} like in React)

[joshwilsonvu]

I'd recommend that a maintainer create a new package eslint-plugin-solid or eslint-plugin-solidjs (whatever's available) and publish it to npm at version 0.0.1. Better to take the package name now than try to arrange a transfer with anyone who might reserve the name first.

[joshwilsonvu]

I got a plugin started at https://github.com/joshwilsonvu/eslint-plugin-solid, with a few basic rules and tests. The ones I listed above are a little more complex so I wanted to get the hang of simpler ones first. Open to suggestions for more rules in this thread or in that repository's Issues.

[lzm0x219]

thanks.

[joshwilsonvu]

I've published the first release of eslint-plugin-solid today and would love any feedback! You can drop any suggestions at https://github.com/joshwilsonvu/eslint-plugin-solid.

I published it myself to get it out there so people can use it today, but I'd be willing to transfer the package into the solidjs organization sometime if that's what's best for the community—just let me know. There's still more work to be done but I think it's in a useful spot.

[ryansolid]

That's awesome I'm going spread it around and see what people think. As I mentioned I'm probably the worst judge of this sort of thing, so I will rely on others feedback (like I do with TypeScript).

[joshwilsonvu]

Thanks! The most useful rules are yet to come, as I do the scope analysis work in ESLint that you’ve already done with Babel. I think when it’s v1.0 it’ll be able to accept most React code and tweak it until it’s idiomatic Solid.