Codestyle and linter

[jankapunkt]

Can we decide for further development for a codestyle and respective linter(-confuguration)?

[StorytellerCZ]

I'm thinking something along the lines of standardx with special addition for Meteor and related.

[jankapunkt]

I agree, it's easy to configure and works very well with Meteor and using --fix it is close to prettier's autofixing.

[distalx]

In one of my projects, We lost a significant amount of historical meta-data when we introduce a prettier & linter at the later stage.

It becomes impossible to figure out that why something is implemented the way it is or how some code is related to which PR/Issue.

So I think if we use any auto formating tool we would lose the historical meta-data.

[jankapunkt]

@distalx I think standardx is not so "hard" in reformatting code like prettier. It often rather throws and only auto formats trivial cases like semicolon, newlines etc.

However, I think this is a valid argument and I'd like to hear more on this.

[filipenevola]

Maybe we should revisit the standards and configurations here https://github.com/meteor/eslint-config-meteor and apply in all our repos.

I have a version of this eslint config that I use in all my projects and it works really well https://github.com/quavedev/eslint-config

We don't need to apply all at once but we can apply when we make changes to specific parts of files.

What do you think?

[distalx]

Gradual adoption would work well when we are adding new files to the repo.

But if someone is making a change to an existing file that would give them a linter-warning if the previously written code is not following the standard that we are going to adopt. And those warnings could become really annoying and someone might reformate those parts as well.

I do believe that having a linter or standard code style setup improves the development experience significantly. We should use a tool or plugin that makes less fuss about the existing code.

And before we go with any solution we should tag the existing version.

[jankapunkt]

I think the adoption should then be started per package for those packages, where no related issues/PRs are in progress or planned. By doing so we ensure the linter will not interfer with current development but also start to adopt already where applicable, right?

[jankapunkt]

@filipenevola @distalx I'd like to bump this issue so do I get it right, that we will now use @quave/eslint-config-quave ?

[filipenevola]

We can use the quave package or update the meteor one, either option work.

[jankapunkt]

As already discussed in #367 we will stick with the @quave config as the main Meteor repo also does