Is there a way to tell eslint-plugin-xstate to treat a block of code as an XState config ?

[markNZed]

I hope it is OK to ask a question here... From what i read in another issue the plugin is usnig the createMachine function to detect the configuration. I'm generating the configuration in another function - is there a way for me to tell the plugin to use another function name of to add directives so it will treat a JS object as an XState config? Thanks and sorry if this is a naive question, I'm running ESLint in VSCode for the first time to try and make use of this plugin.

[rlaffers]

No, this is not possible, however, it is a good idea. I will explore this.

[rlaffers]

OK, so we could have a comment like this:

/* eslint-plugin-xstate-include */

This would force the linting rules over the entire file, not only the code within createMachine calls. What do you think? I'm not sure whether the name for the directive is clear enough.

[markNZed]

That would work in my case because the XState configuration is in a dedicated file but I could imagine people mixing XState with other code and it highlighting many issues outside of the XState config.

Can we limit the / eslint-plugin-xstate-include / so it will operate within the current context e.g. it could be placed inside the function.

Another idea can we configure the name of the "createMachine" function ?

[rlaffers]

While I agree that having a directive for indicating a portion of code for linting would be more powerful, I don't think this is feasible. AFAIK, there is no API in ESLint which would easily allow for this. Having to go by comments first, we would be unable to use AST selectors, since comments cannot be targeted by selectors but must be parsed from the source code separately.

I am not sure how useful it would be to have the capability to rename the createMachine function. I haven't had any requests about this yet and I myself haven't had any need to rename it in my code bases. Anyway, adding the comment directive is probably going to help with this situation too, so I'd skip on this one for now.

[markNZed]

I know close to nothing about ESLint but what you've explained makes sense. It must be uncommon to wrap the createMachine but if you want to build more abstract features than what XState provides it is a simple way to have a sort of "middleware" e.g. there may be other systems that will modify the configuration of the machine before it is "created". The comment directive would be great for me, I would certainly use it. At the moment it take a bit of time to create a "fake" createMachine so I would need to be stuc kin debug before going through that.

[rlaffers]

Interesting. Can you perhaps provide a code example?

[markNZed]

I could but it is mixed into a large prototype that will make it hard to follow. Here is a basic idea:

1) a task that is defined in part by a FSM 2) a configuration of the task (i.e. there can be multiple instances of the task) 3) a deep merge to overwrite the functionality of the FSM depending on the configuration of the task

[github-actions[bot]]

:tada: This issue has been resolved in version 2.2.0 :tada:

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[rlaffers]

This feature is now available in eslint-plugin-xstate@next

https://github.com/rlaffers/eslint-plugin-xstate/tree/next#comment-directives

[markNZed]

Confirmed working in VSCode thanks for the amazing turnaround!