General cleanup with eslint updates

[brody2consult]

UPDATED after review and discussion:

• merge changes from PR remove no-throw-literal lint exception not needed #81 to remove standard eslint exceptions from .eslint.yml that are not needed
• manual cleanup fix for no-prototype-builtins (as needed by new (semi)standard eslint package updates)
• eslint-config-semistandard@14 & eslint-config-standard@13 updates with automatic cleanup fixes (since the prefer-const & quote-props eslint rules are now enabled)
• automatic eslint cleanup fixes for padded-blocks that is no longer kept as an exception

I tried to keep these changes split into separate commits in a semi-sensical manner. I think it would be a little too much to put all these changes into a single commit. I am now proposing the most important changes in this PR for discussion, with some apparently controversial changes now split into separate PRs.

My objective is to keep the number of (semi)standard eslint exceptions to a bare minimum.

[codecov-io]

Codecov Report

Merging #82 into master will decrease coverage by <.01%.
The diff coverage is 71.42%.

@@            Coverage Diff             @@
##           master      #82      +/-   ##
==========================================
- Coverage   89.04%   89.04%   -0.01%     
==========================================
  Files          20       20              
  Lines        1826     1825       -1     
  Branches      374      373       -1     
==========================================
- Hits         1626     1625       -1     
  Misses        200      200

Impacted Files	Coverage Δ
src/CordovaLogger.js	98.46% <ø> (ø)	⬆️
src/util/addProperty.js	100% <ø> (ø)	⬆️
src/ConfigChanges/ConfigChanges.js	94.18% <ø> (ø)	⬆️
src/CordovaError/CordovaError.js	89.28% <100%> (-0.37%)	⬇️
src/util/xml-helpers.js	98.79% <100%> (ø)	⬆️
src/superspawn.js	88.7% <100%> (ø)	⬆️
src/PlatformJson.js	82.69% <100%> (ø)	⬆️
src/FileUpdater.js	86.01% <25%> (ø)	⬆️
src/ConfigParser/ConfigParser.js	78.64% <50%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 83954d6...112b5cd. Read the comment docs.

[janpio]

same as #81 (review)

[raphinesse]

My opinion regarding these changes:

• ✔️ Re-enable padded-blocks rule
  One minor nitpick: I don't like the generous empty lines you added to the require blocks.
• ✔️ Re-enable no-throw-literal rule
• ✔️ quote-props fixes
• ✔️ (semi)standard eslint updates
• ❌ Disable no-unused-vars rule
• ❔ Re-enable operator-linebreak rule
  I think it's good to enforce one style here, although I tend to favor the before style, especially with boolean operators.

I'd also like to remove camelcase: off. But this one will make a lot of noise, so I think we should approach it in a separate PR. Plus we will have to see how many exceptions we have to make for our public interface here.

All in all, this looks very good to me 👍

[raphinesse]

@janpio I think consistency with other repos should not be a matter here, if we see this as a test drive towards a better, stricter code style.

I'm ok with it if it is part of a bigger initiative that will be used in a project wide context.

[brody2consult]

I just pushed the more important changes in a different order, in a cleaner sequence, and rebased on master. I moved the seemingly controversial proposals out to separate PRs #85 & #86. I would really appreciate another review.

I pushed the original proposal into my general-cleanup-with-eslint-update-save1 branch in case we want to keep it for comparison..

[raphinesse]

Approved with my suggested change. Thanks for updating this PR.

[brody2consult]

I applied the change suggested by @raphinesse, with the code alignment fixed, preserved these updates in my general-cleanup-with-eslint-update-save2 branch, then rebased the changes as 3 commits on top of the master branch.

I think these changes should be good to go, would appreciate a final review.

I am not sure whether these changes should be merged by a merge commit or rebase commit (I would not favor a squash merge). The merge commit would clearly show that these changes go together with this PR number, while the rebase commit might be a little less noisy. (GitHub would still show the PR number for each of the commits, though.)

[raphinesse]

LGTM, thanks for the update!

I'd merge this as an actual merge. But do as you see fit.