Fix prettier, eslint and stylelint config

[dijitali]

Fixes

• Fixes [Feature] enable Prettier to run automatically #520 by @dijitali

Description

Fixes prettier, eslint and stylelint config. Now run manually via npm run lint and npm run format as discussed in #530 (comment).

Technical details

Add and configure husky to run lint-staged (latest v8.x, since v9 drops node v14 support):
npm install --save-dev [email protected]
npx husky add .husky/pre-commit npx lint-staged

1. Upgrade Prettier and add npm run format scripts:
   npm update prettier

2. Downgrade eslint-config-prettier to be compatible with eslint v6 (current v7.2.0 requires eslint upgrade):
   npm install --save-dev [email protected]

3. Ignores coverage and dist directories when running Prettier

4. Update lint-staged to run prettier

5. Remove git-hooks config from package.json (this project uses Husky not Yorkie)

6. Check eslint <-> prettier conflicts and remove problematic rules:

   npx eslint --print-config src/App.vue | npx eslint-config-prettier-check
   
   #The following rules are unnecessary or might conflict with Prettier:
   
   # - comma-dangle
   # - indent
   # - space-before-function-paren

7. Set lint-staged to run stylelint on the same file patterns as the npm script is configured to. This potentially needs further work as a separate PR because currently on main, if you run npx stylelint **/*.{css,vue} --fix (the equivalent of what lint-staged runs it against), there's a bunch of things flagged in the static directory.

Tests

1. Run npm run lint and npm run format and check that tests and builds still work OK
2. Try committing a change with incorrect formatting and verify that it's fixed when you next run the lint and format commands

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the default branch of the repository (main or master).
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added or updated tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no
  visible errors.

Developer Certificate of Origin

For the purposes of this DCO, "license" is equivalent to "license or public domain dedication," and "open source license" is equivalent to "open content license or public domain dedication."

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[netlify]

✅ Deploy Preview for creativecommons-chooser ready!

Name	Link
🔨 Latest commit	0beb045
🔍 Latest deploy log	https://app.netlify.com/sites/creativecommons-chooser/deploys/66c70da02990cc00070aeb87
😎 Deploy Preview	https://deploy-preview-530--creativecommons-chooser.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[dijitali]

NB: these changes might be problematic with the new docker setup of this project (#517). If git commits are made on the host machine and git hooks don't execute within the container, then node, npm and packages may not have been installed so the hooks will fail.

I'm not aware of a general solution for a containerised application with git hooks but from a quick look:

1. leave things as they are and setup sharing of git credentials into the container (e.g.. for dev containers with VSCode)
2. change git hooks to user docker compose exec ... commands instead of npm run ... etc. This would basically mandate the use of docker when working with this project
3. or just disable all git-hooks and leave code linting/formatting to be a manual step.

[possumbilities]

@dijitali after considering this, I'm thinking the best option you've outlined is likely just disable all git-hooks and leave code linting/formatting to be a manual step.

It's a tradeoff for sure, but it does mean that there's less likelihood of things failing. We don't automate prettier in other repositories, so I think there's enough of a pattern there for it not to be an outlier in that regard.

[dijitali]

Yep, makes sense I think 👍

Am aware that this repo is due/blocked for a major upgrade (#356) which would perhaps negate the fiddly docker requirements.

However given that this project is referenced to as an exemplary javascript project in the guidelines and that this repo already has some partially functional config, would it be good to just get the prettier/eslint config in a functional state and leave out the automatic execution?

[possumbilities]

Yep, makes sense I think 👍

Am aware that this repo is due/blocked for a major upgrade (#356) which would perhaps negate the fiddly docker requirements.

However given that this project is referenced to as an exemplary javascript project in the guidelines and that this repo already has some partially functional config, would it be good to just get the prettier/eslint config in a functional state and leave out the automatic execution?

Yeah, I think improvements here, even if automating them isn't reasonable, are still worth doing until the project is upgraded, or refactored in other ways.

[dijitali]

@possumbilities - think this is all set for a re-review when you have a chance 🙏

Oh and if you had the git hooks installed on your local machine, Husky v8.0.3 docs say to remove them with:

git config --unset core.hooksPath