According eslint config

[JJ]

Codebase contains multiple violations of current eslint validation/style rules, unfortunately fixing some of these would lead to breaking compatibility with existing installations (inability to properly handle stored data).

So here comes the question: since all data is available in the remote store can we fix everything, clear the local storage and just re-fetch everything, or that would be too annoying for the user? If we can’t should we build some storage converter to run on update and still clean up the codebase?

Additionally in some places violations are forced by API expecting inconsistent field names (sometimes snake_case and sometimes camelCase), my idea would be to quote field names that are not locally defined to differentiate them from local style.

[Pierre-Adrien Buisson]

I fixed a bunch of warnings and errors, but I honestly am not that focused on the linter feedback. It gives interesting feedback but I don’t feel like we need to update the local storage just so that linters warnings are fixed.

Still, we must strive to follow linter advice, but most remaining issues are related to snake_case variable names (I believe I kept those to stick to Pocket API at the beginning, which was maybe not the smartest choice), and lines > 100, mostly for logging…. so good enough for now I guess.

[Pierre-Adrien Buisson]

For now, I'll close this one. I simply make sure to strive to have as few eslint errors as possible, but this is definitely not a big issue to me, and not something I wan’t to spend time or energy on compared to all the other features or fixes that would require my attention