Possible linter rules

[samturrell]

Hi @netsells/frontend,

Currently i just bookmark linter rules when i encounter code where a rule might be useful. This isn't entirely helpful for the wider team, so i'm going to move to them into comments on this post if and when anyone has time to pick them up.

Early next year i will be looking to enforce regular contributions to our linting tools to ensure that they are regularly expanded on with a set of agreed rules, so it will be helpful for people to just pick one out of this thread and run with it.

[samturrell]

https://eslint.org/docs/rules/sort-imports

Sort imports in javascript.

This will keep PRs clean as the order won't change with each PR/user preference

[samturrell]

https://eslint.org/docs/rules/arrow-body-style

Keep single, simple returns as inline arrow returns

e.g.

// Bad
this.items
    .filter(({ thing }) => {
        return thing === true;
    })
    .map((item, index) => {
        return {
            id: index,
            ...item,
        };
    })
    .find(({ id }) => {
        return id === 123;
    });

// Good
this.items
    .filter(({ thing }) => thing === true)
    .map((item, index) => ({
        id: index,
        ...item,
    }))
    .find(({ id }) => id === 123);

[samturrell]

@BeccaAnderton why the thumbs down?

[BeccaAnderton]

@samturrell I'm sure we've discussed before 😅 It's entirely a personal preference and not really anything against the rule, but I really struggle to interpret functions like this when they're written without the return - I find myself having to update them to include it to work out what's going on when debugging issues etc

[samturrell]

@samturrell I'm sure we've discussed before 😅 It's entirely a personal preference and not really anything against the rule, but I really struggle to interpret functions like this when they're written without the return - I find myself having to update them to include it to work out what's going on when debugging issues etc

Makes sense. I just think it's a shame that we have a language feature that reduces code that we're not utilising consistently.

Happy to bring it to a vote/discussion if/when we come to implement the rule though.

[BeccaAnderton]

@samturrell I'm sure we've discussed before 😅 It's entirely a personal preference and not really anything against the rule, but I really struggle to interpret functions like this when they're written without the return - I find myself having to update them to include it to work out what's going on when debugging issues etc

Makes sense. I just think it's a shame that we have a language feature that reduces code that we're not utilising consistently.

Happy to bring it to a vote/discussion if/when we come to implement the rule though.

I wouldn't expect you not to include the rule if everyone else is happy with it, just because of my personal preference

[samturrell]

https://eslint.vuejs.org/rules/template-curly-spacing.html

Enforce spacing on template strings. We already have this rule for javascript, but this will enable it for vue templates.

e.g.

<p>hello, {{name}}!</p>

would require

<p>hello, {{ name }}!</p>

[samturrell]

https://eslint.vuejs.org/rules/attributes-order.html

Consistent ordering of attributes.

I like v-if being at the top so it's easier to see conditional rendering. The other stuff is just a bonus