chore: enforce arrow style functions

[thisislawatts]

PR Checklist

• - Commit messages are descriptive, it will be used in our Release Notes

PR Type

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Developer experience (improves developer workflows for contributing to the project)

Description

An exploration at using automation to standardise on arrow style function declaration. Based on the following comment in another PR.

Suggestion (not-blocking) : Could change this to be an arrow function to be in line with the other functions
#2133 (comment)

---

What happens next?

Thanks for the contribution! We try to make sure all PRs are reviewed ahead of a monthly dev call (first Monday of the month, open to all!).

If the PR is working as intended it'll be merged and included in the next platform release, if not changes will be requested and re-reviewed once updated.

If you need more immediate feedback you can try reaching out on Discord in the Community Platform development channel.

[cypress]

1 flaky tests on run #3069 ↗︎

0

78

3

0

1

Details:

Merge branch 'master' of https://github.com/ONEARMY/community-platform into chor...
Project: onearmy-community-platform	Commit: 5d98bf4078
Status: Passed	Duration: 03:29 💡
Started: Mar 22, 2023 2:41 PM	Ended: Mar 22, 2023 2:45 PM

  src/integration/common.spec.ts • 1 flaky test • ci-chrome

View Output Video

Test		Artifacts
[Common] > [User Menu] > [By Authenticated]		Output Screenshots

_{This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.}

[AlfonsoGhislieri]

Praise @thisislawatts this was so satisfying to look at! Looks good to me 👍🏻

The only thing I was worried about was the implicit returns like mentioned here, but it seems that all the non one liners are wrapped in parathenses which should not cause any issues.

[chrismclarke]

Looks good to me also, I similarly took a quick google of any use-cases when it might be better to keep function notation and couldn't find any examples in the changes mentioned so say should be good to go once conflicts resolved (will take a quick look)
https://www.javascripttutorial.net/es6/when-you-should-not-use-arrow-functions

[thisislawatts]

Thanks @chrismclarke, I think the quickest way to do this would be drop 52454b9, then rebase against master addressing any merge conflicts on .eslintrc.json and then run yarn format which will apply all of the necessary changes.

[chrismclarke]

I think the quickest way to do this would be drop 52454b9, then rebase against master addressing any merge conflicts on .eslintrc.json and then run yarn format which will apply all of the necessary changes.

Dropping commits extends a bit beyond my git-foo, so for now I've just manually resolved for a second time (expect a few minor conflicts like this as trying to get more of the backlog merged in) - cool to know it auto-formats the rule though, I've just re-run on the merged branch and no new changes detected so will merge ahead of other PRs once tests complete

[onearmy-bot]

🎉 This PR is included in version 1.41.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀