Pinia Eslint plugin

[MickL]

What problem is this solving

Would be cool to have an Eslint plugin that provides best practices. E.g. With a setup store all variables need to be exported (according to the docs) and a plugin could warn / error if we forgot to export a variable / function.

Maybe there are more best practices or anti patterns that the plugin could warn / error about.

Proposed solution

Describe alternatives you've considered

No response

[posva]

Yes, I've been hoping for an eslint expert to show up for the last 3 years 😄. I still haven't lost hope

[lisilinhart]

I've been looking into what rules would make sense for a pinia eslint plugin. Looking at the docs and came up with some ideas, what do you think @posva and @MickL?

• prefer-use-store-naming-convention: Enforces the convention of naming stores with the prefix use followed by the store name and suffixed with Store
• prefer-single-store-per-file: Encourages defining each store in a separate file
• require-setup-store-exports: Checks the structure of stores defined using the setup function, ensuring state variable properties are returned.
• no-return-global-properties: Warns against returning global properties like route or appProvided in setup stores.

[MickL]

Sounds very good! Would it be possible to enforce that ALL variables that are defined in the store also need to be exported by the store?

[lisilinhart]

Hi @MickL, here is the first version including three rules, I tried it with a vue scaffold already:

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

[posva]

Nice, thanks a lot for the initiative @lisilinhart ! A few notes regarding the rules:

• prefer-use-store-naming-convention: Yes for the use but maybe the Store suffix should not be activated by default because it's okay to name it something differently like Service or other name. So I think it should be configurable
• prefer-single-store-per-file: I don't think this should be activated by default or maybe it should be applied only to exported stores, only one exported store. I'm thinking of this https://masteringpinia.com/blog/how-to-create-private-state-in-stores. In that case you might even export the private store for testing purposes and it's not convenient to split it into multiple files
• require-setup-store-exports: I think the default should only apply to ref, reactive and other state properties. It shouldn't warn for missing functions, computed or raw data (not state)
• no-return-global-properties: 👍

As for other other ideas:

• 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

What do you think?
I think Discussions is a great place to find where people are struggling

[lisilinhart]

Hey @posva, thanks for the detailed feedback. Your suggestions make a lot of sense and I'll look into adding those changes into the already existing rules in the next few days. I thought the same thing about only warning around ref reactive, it makes sense not to warn about more constant / helper variables or inner functions. I also need to look into more detail, which ones would be possible to autofix.

Discussions sounds like a good place to gain insight from actual use cases, should I open one and summarise the points that were mentioned here?

[posva]

Feel free to open a discussion if that helps you

[MickL]

Hey @lisilinhart this sounds amazing! Unfortunately I am currently focusing on backend work but next week I will be back at Nuxt and try it out!

[lisilinhart]

Feel free to open a discussion if that helps you

I opened the discussion here: #2638