mxcube / mxcubeweb

MXCuBE-Web
http://mxcube.github.io/mxcubeweb/
GNU Lesser General Public License v3.0
20 stars 38 forks source link

Enforce Prettier formatting? #1313

Open fabcor-maxiv opened 1 month ago

fabcor-maxiv commented 1 month ago

As noted here: https://github.com/mxcube/mxcubeweb/pull/1312#issue-2402744451

There is a conflict between yamllint and prettier. Somehow this conflict has not appeared in the GitHub checks.

There is no prettier in the pre-commit hooks. But there is prettier in some GitHub Actions workflow.

Should be investigated how come the conflict did not appear. Is the prettier formatting really checked in the GitHub Actions workflow? What is going on?

axelboc commented 1 month ago

Wasn't Prettier just running after yamllint, and therefore "winning" over it?

marcus-oscarsson commented 1 month ago

I think this was the issue:

https://github.com/prettier/prettier-vscode/issues/278

So vscode seems to run the default formater on save if not explicitly told not to for a specific file type. So we need to add (to .vscode/settings.json):

  "[yaml]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },

EDIT and add yamllint instead

marcus-oscarsson commented 1 month ago

Well, so its more editor configuration issue perhaps but sill worth addressing so that its the same for everyone. I guess I'm not alone to use vscode

fabcor-maxiv commented 1 month ago

I think we should have prettier in the pre-commit hooks, right? At the same time we should remove it from the other GitHub Actions workflow, so that we do prettier formatting in one single place: in the pre-commit hooks. I can probably take care of that.

I do not use vscode, so I will likely not be the one to take care of that part.

axelboc commented 1 month ago

Always good to keep a sanity check on the CI (EDIT: the CI doesn't actually do the formatting; it just checks if it's formatted), as pre-commit hooks are easily bypassed.

axelboc commented 1 month ago

Personally, I prefer format-on-save in the editor instead of commit hooks, as commit hooks can slow down committing and negatively affect DX. But I admit they're convenient in a project like this where not everyone will have their editor configured to format-on-save.

fabcor-maxiv commented 1 month ago

Always good to keep a sanity check on the CI, as pre-commit hooks are easily bypassed.

Personally, I prefer format-on-save in the editor instead of commit hooks, as commit hooks can slow down committing and negatively affect DX.

Yes, sorry, I was being unclear, we already have a GitHub Actions workflow job somewhere that does pre-commit run --all-files:

https://github.com/mxcube/mxcubeweb/blob/e1932141cdb28c66ca86468eedc9f952a26bc5b3/.github/workflows/build_and_test.yml#L56

So my plan is:

  1. move this out of the workflow it is currently buried in and move it into a more prominent place in its own workflow (right at the beginning so that we do not waste time running any other GitHub checks if pre-commit hooks fail).
  2. get prettier into a pre-commit hook
  3. remove the other occurrences of prettier formatting so that it is done only once

Installing and running pre-commit hooks locally should not be mandatory, because we run them in a GitHub Actions workflow anyway.

marcus-oscarsson commented 1 month ago

Sounds perfect !

fabcor-maxiv commented 1 month ago

I now realize that while the pre-commit tool is a near de facto convention in Python world, it is far from being the case in JavaScript world and I can not seem to find an equivalent, my grand master plan is foiled! : D

I will keep investigating, there are a bunch of things I would like to improve in the GitHub Actions workflows anyway...

But if I understood correctly the issue was in the IDE settings, right? There isn't anything that needs immediate attention, is there?

marcus-oscarsson commented 1 month ago

Yeah, there is nothing urgent :) Thanks for having a look !