Makes linting run before code is committed

[madsnedergaard]

Description

We want to improve linting and make the codebase more standardized.

This PR makes linting and formatting happen automatically before code is committed.

Steps:

• Add config (Adds prettier packages and updates eslint dependencies #4128)
• Lint everything (Prettifies everything #4134 )
• Setup husky and lint-staged for keeping things linted going forward (this PR)

[VIKTORVAV99]

Consider running prettier on the /.circleci, /.github and /config directories/folders as well.

Probably won't do much on the first two but ruining it on the last would be nice so the config files all have the same formatting throughout. (mostly affecting zones.json and exchanges.json)

[madsnedergaard]

Oh yes, that's a great point! Since those are outside of web and are often edited through the browser, maybe running it in a GH action or CI like you suggested would be ideal? :)

[VIKTORVAV99]

Sounds like we have a plan then!
I'll create a PR after the others are merged.

[madsnedergaard]

Sounds like we have a plan then! I'll create a PR after the others are merged.

Awesome!
We are actually already running a "lint JSON" step in CircleCI:

sudo npm install -g jsonlint-mod
jsonlint -q config/*.json web/public/locales/*.json

[VIKTORVAV99]

Sounds like we have a plan then! I'll create a PR after the others are merged.

Awesome! We are actually already running a "lint JSON" step in CircleCI:

sudo npm install -g jsonlint-mod
jsonlint -q config/*.json web/public/locales/*.json

This would differ somewhat though, prettier formatting can fail even if linting passes.
An example would be:

"capacity": [
      -533,
      533
    ]

and

"capacity": [-533, 533]

both will pass linting but only the second one will pass prettier.

Now just adding prettier to check if the formatting is right is as simple as it gets but if we want prettier for format it too it gets a little more complicated as it will create a new commit but still very doable (I am personally running it this way in a private repo with a github actions workflow).
I can't say I know off hand how to do it in CircleCI but it can't be that hard to figure out.

[madsnedergaard]

Now just adding prettier to check if the formatting is right is as simple as it gets but if we want prettier for format it too it gets a little more complicated as it will create a new commit but still very doable (I am personally running it this way in a private repo with a github actions workflow). I can't say I know off hand how to do it in CircleCI but it can't be that hard to figure out.

Hmm, the committing changes part is actually a problem with forks (see discussion here: #4131) 🤔
Not sure how to best approach it, but maybe just checking (and failing on changes) is an okay first step? We could reuse/change the lint_json step in CircleCI to do this.

[VIKTORVAV99]

I left a comment on the other PR but yeah just doing a check seems like the only option for now and it should be fine for most scenarios.

While reusing existing jobs are a option I think we want to do as much in parallel as we can to reduce CI run durations.
So it might make sense to create a separate job for it, would be easier to tell if it was linting or formatting that failed too.

[madsnedergaard]

This fixed the annoying problem when running yarn install and seeing a bunch of errors from fsevents/node-pre-gyp :)

[VIKTORVAV99]

It also fixes a bunch of security vulnerabilities. 👀

I was actually planning on submitting a PR for it after the current PRs that target the lock file was merged.

[Kongkille]

Excellent 👌

Edit: I'm just going to go ahead and fix the merge conflicts

[madsnedergaard]

Thanks for fixing and merging ❤️