Kolibri: Create linting rules to check for unused props, data, computed props, and vuex mappers

Created on 9 Feb 2019  路  6Comments  路  Source: learningequality/kolibri

Observed behavior

Currently we have no way of auditing our components to see whether any of our component data is used inside of the component itself. This means that our components slowly accrue cruft over time.

Expected behavior

Our linting should give an error when any of a prop, data, computed props, vuex mapped getters, and state are unused.

In addition, it could also warn for methods, and mapped actions that are unused anywhere in the component.

dev experience

Most helpful comment

I've started working on it.

All 6 comments

I'll try to prepare a first simple version of one or two rules and after we see how it works, I think that we could also possibly ask _eslint-plugin-vue_ folks if they would be interested in using code and implementing those rules right within _eslint-plugin-vue_ ? All of them are really general rules that might be useful in many projects and for us, getting some wider support from Vue community would be also nice I think.

And it seems they already have some of them in their todo list :)

https://github.com/vuejs/eslint-plugin-vue/issues/848
https://github.com/vuejs/eslint-plugin-vue/issues/631

Yeah, I made this issue because I was surprised that they didn't already exist, anything we can do to have them maintained externally is fine by me!

Although, I note that neither of these are vuex specific (due to the way that the vuex mappers work, this would probably need to be implemented separately to the no unused vars/props etc).

No problem, I'm actually planning to split it anyway for the first version and use utility functions for some common functionality. I would rather start small. It can be merged into one rule if needed later - this will be easier when compared to breaking one rule into more of them. So we should be able to provide some of them to _eslint-plugin-vue_ and keep the rest of them as our custom rules and eventually merge them if that would be more appropriate for us.

I think the general tendency in eslint rules (which is continued in eslint-plugin-vue) is to make rules very small, so that they can be turned on and off as desired, so I think it makes perfect sense to separate out vuex specific rules from regular vue ones.

I've started working on it.

Was this page helpful?
0 / 5 - 0 ratings