refactor: mutate config in normalizeConfig and handleLocalBackend fns

[smashercosmo]

Summary

Another atomic PR to make #4776 easier to merge

Test plan

Run current tests

[smashercosmo]

Seems like latest commits from master cause e2e tests to fail

[erezrokah]

Seems like latest commits from master cause e2e tests to fail

👀

[smashercosmo]

Hm... now I have no idea why it fails. When I run e2e tests locally they pass.

[smashercosmo]

@erezrokah I think I'm gonna need your help with it ((

[erezrokah]

Sorry for the delay @smashercosmo. I'm clearing some stuff off my plate and we'll review the PRs this week.

[erezrokah]

@smashercosmo This seems like an issue with Cypress https://github.com/netlify/netlify-cms/pull/4846/checks?check_run_id=1791036988#step:7:1195

[erezrokah]

I'm going to try and revert the Cypress version per cypress-io/cypress#14663

[erezrokah]

Sorry for the delay @smashercosmo, thank you for another great PR which makes our codebase much cleaner and easier to understand.

I decided to keep the methods non-mutating as personally I believe they make the code easier to follow.

[smashercosmo]

hm... @erezrokah I understand you concern, but if you want to keep methods immutable, I would suggest we just use immer instead of object spreads.

[erezrokah]

hm... @erezrokah I understand you concern, but if you want to keep methods immutable, I would suggest we just use immer instead of object spreads.

That's a good point. I wasn't sure if the the nesting was deep enough to justify that.

[smashercosmo]

@erezrokah another question not directly related to this PR but to netlify-cms code style in general. I noticed that you're using both function expressions and function declarations across codebase, but seems like there is no logic in when either is being used. I would propose to use function expressions only in inline callbacks and declarations in all other cases. Because it's easier to distinguish function from a simple variable when function is declared as declaration.
Bad:
const someVar = 1
const someFn = () => { ... }

Good:
const someVar = 1
function someFn() { ... }

[erezrokah]

Another good point. We mostly care about consistency (which we don't have).
What do you think about adding https://eslint.org/docs/rules/func-style to our linting configuration?

[smashercosmo]

Well, surely I can, but should I then fix all of the eslint errors? 🙂

[erezrokah]

I'm mostly interested on how many errors we get :) we can apply the rule for specific parts of the codebase and slow fix errors, or add it as a warning?

[smashercosmo]

618 errors 🙂 I'll check if it can be fixed by some codemod