Add pre-commit config with ruff and prettier

[consideRatio]

pre-commit, and the rust replacement prek is a CLI that helps run autoformatters etc configured via a .pre-commit-config.yamlfile, and can be configured to run before yourgit commitsucceeds as a git hook by usingprek install` for example.

I have configured prek / pre-commit to use ruff and prettier, where prettier makes use of plugins for formatting xml, and java. Out of the box we get formatting for markdown, json, yaml, html, css, for example.

• fixes Set up formatters and linters in CI #114

Meant to go hand in hand with activating pre-commit.ci via https://pre-commit.ci/ for automation integrated with GitHub to check the pre-commit hooks run correctly. We could also have a github workflow / job for this, but the pre-commit ci is very fast, no maintenance, and helps with both updates of the pre-commit hook versions and can push commits to PRs with fixes (can be opted out of).

Why .pre-commit-hooks.yaml?

I appreciate use of .pre-commit-hooks.yaml (with prek or pre-commit) because:

• I am familiar to this already and have used them successfully for a long time
• We would like this ensure the full repo is being autoformatted, and avoid needing to have multiple configs for this project which has various subprojects, and have each subproject lint
• We get very good coverage of file types with few formatters involved (ruff + prettier)

Why pre-commit.ci to run the check?

I appreciate use of pre-commit.ci to run the automated checks as it offloads us from maintaining another Github workflow job, and has worked reliably and efficiently for a long time now. It also helps us bump the versions, and if we want, also push commit with fixes.

[andrius-puksta-sensmetry]

Just a note: prek is a faster alternative. It reads the same .pre-commit-config.yamland is mostly a drop-in replacement.

[consideRatio]

Just a note: prek is a faster alternative. It reads the same .pre-commit-config.yamland is mostly a drop-in replacement.

Nice I hadn't heard about it before, tested it now and am happy about the outcome!

[andrius-puksta-sensmetry]

Have/will you set this up on sysand repo side?

[andrius-puksta-sensmetry]

Or does this need setup per-person?

[consideRatio]

I don't remember off the top of my head, but its a matter of a change in the github repo or github or org settings, adding pre-commit.ci as an integration with no further config needed etc.

I typically go to org settings in jupyterhub, enabling it for another specific repo as we add a project.

Edit: under github org settings, third party apps. However, it needs to be initially setup, so maybe via pre-commit.ci website i think

[andrius-puksta-sensmetry]

Also, maybe renovate can update deps here?

[andrius-puksta-sensmetry]

LGTM

[victor-linroth-sensmetry]

Just because something hasn't been included in the CI (yet) doesn't mean it's not used.

[victor-linroth-sensmetry]

Having thought about this a bit more and I still would prefer to handle the Java and pom.xml formatting through the Spotless Maven plugin for a two reasons:

• Spotless together with Checkstyle can cover both formatting and linting based on the Google Java Style Guide (which seems to be the most dominant Java style a.t.m.). From what I can tell Prettier formats things differently and could potentially come to conflict with the linter.
• Both have Maven plugins that integrates directly into the build process and so gets automatically enforced in CI.

[consideRatio]

Having thought about this a bit more and I still would prefer to handle the Java and pom.xml formatting through the Spotless Maven plugin for a two reasons:

• Spotless together with Checkstyle can cover both formatting and linting based on the Google Java Style Guide (which seems to be the most dominant Java style a.t.m.). From what I can tell Prettier formats things differently and could potentially come to conflict with the linter.
• Both have Maven plugins that integrates directly into the build process and so gets automatically enforced in CI.

Thank you for reviewing this @andrius-puksta-sensmetry and @victor-linroth-sensmetry!!

For now I removed the addition related to XML and Java autoformatting. The XML was broken in how it formatted things, and probably caused issues by itself.

Findings about the the prettier-java plugin

• The google java style guide is adhered to at least with regards to import ordering: https://github.com/jhipster/prettier-java?tab=readme-ov-file#organize-imports
• There is a checkstyle configuration so that such linting is compliant with the plugins opinionated formatting: https://github.com/jhipster/prettier-java?tab=readme-ov-file#checkstyle-configuration

Notes on re-activating the prettier-java plugin

If we want the Java formatter in the future from pre-commit's prettier system, we should add a .prettierrc.mjs file with the following content in order to activate the plugin once its available in the environment.

import { createRequire } from "module";

const require = createRequire(import.meta.url);

const javaPlugin = await import(require.resolve("prettier-plugin-java"));

export default {
  plugins: [javaPlugin.default],
  overrides: [
    {
      files: "*.java",
      options: {
        tabWidth: 4,
      },
    },
  ],
};

And in our .pre-commit-config.yaml, add the following to the prettier hook:

        additional_dependencies:
          # https://www.npmjs.com/package/prettier
          - "prettier@3.8.1"
          # https://www.npmjs.com/package/prettier-plugin-java
          - "prettier-plugin-java@2.8.1"

[victor-linroth-sensmetry]

Not sure I fully understand how pre-commits work, but seems worth trying out.