pinia
pinia copied to clipboard
Pinia Eslint plugin
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
Yes, I've been hoping for an eslint expert to show up for the last 3 years 😄. I still haven't lost hope
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 withStore
- 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.
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?
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
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 theStore
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 https://github.com/vuejs/pinia/issues/1394
- Disallow modifying state: https://github.com/vuejs/pinia/issues/58 (should be off by default)
- Avoid
storeToRefs()
in crossed used stores https://github.com/vuejs/pinia/discussions/2633
What do you think? I think Discussions is a great place to find where people are struggling
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?
Feel free to open a discussion if that helps you
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!
Feel free to open a discussion if that helps you
I opened the discussion here: https://github.com/vuejs/pinia/discussions/2638