Eslint Pinia Plugin - Best Practices

[lisilinhart]

The beginning of this discussion came from this issue from MickL identifying the need for an eslint plugin that could enforce best practices and prevent common errors. I started looking at the pinia documentation and some common suggestions made there and created a new plugin here:

• Repo: https://github.com/lisilinhart/eslint-plugin-pinia
• Package: https://www.npmjs.com/package/eslint-plugin-pinia

@posva provided some feedback on the first few rules, including considerations for configurable options and refining the scope of certain rules. Right now the set of existing rules are the following:

• prefer-use-store-naming-convention: Enforces the convention of naming stores with the prefix use and configurable with a prefix
• require-setup-store-exports: Checks the structure of stores defined using the setup function, ensuring state variable properties are returned.
• prefer-single-store-per-file: Encourages defining each store in a separate file (this might be disabled by default, since it clashes with private stores as @posva pointed out)
• no-return-global-properties: Warns against returning global properties like route or appProvided in setup stores.

Furthermore @posva already gave some more suggestions toward other helpful rules:

• Unique store ids Warn if two stores are defined with the same name #1394
• Disallow modifying state: Add an option to disallow direct state modification from component #58 (should be off by default)
• Avoid storeToRefs() in crossed used stores Using storeToRefs inside of another store is not working #2633

The next steps involves refining the proposed rules based on feedback and implementing the rules that already have been suggested. I am opening a discussion to gather further insights from the community. Since the plugin should be helpful for a wide audience of pinia users, I'm aiming to create rules that make sense for across various projects (through configuration) or are helpful in preventing common errors.

[kazupon]

What a great start to a great discussion this is!
I am currently a Vue consultant for a company. That company has already used pinia, and I need some suggestions by @posva.
In my case, I especially need a unique store ID linting.

[kazupon]

• Unique store ids Warn if two stores are defined with the same name #1394

It would be desirable to have a require-literal-store-id rule that requires the store id to be literal in relation to this rule.
If the store-id is dynamic, there is a risk of duplicate store-ids being defined.

[posva]

This rule is worth adding: #2848 (comment)