mirrors-prettier VS pre-commit

repos: - repo: https://github.com/pre-commit/mirrors-prettier rev: hooks: - id: prettier files: \.(json|markdown|md|yaml|yml)$

note, we also need to add prettier itself too because usually JavaScript hooks use additional_dependencies to install libraries that hook uses, here is example

yaml repos: - repo: https://github.com/myint/autoflake rev: v1.4 hooks: - id: autoflake args: - --in-place - --remove-all-unused-imports - --expand-star-imports - --remove-duplicate-keys - --remove-unused-variables - repo: https://github.com/asottile/pyupgrade rev: v2.29.0 hooks: - id: pyupgrade args: [--py36-plus] - repo: https://github.com/PyCQA/isort rev: 5.9.3 hooks: - id: isort - repo: https://github.com/psf/black rev: 21.10b0 hooks: - id: black args: [--safe, --quiet] - repo: https://github.com/PyCQA/flake8 rev: 4.0.1 hooks: - id: flake8 - repo: local hooks: - id: pylint name: pylint entry: pylint language: system types: [python] args: [ "-rn", "-sn", ] - repo: https://github.com/pre-commit/mirrors-mypy rev: v0.910-1 hooks: - id: mypy name: mypy entry: mypy language: python types: [python] args: [] require_serial: true - repo: https://github.com/pre-commit/mirrors-prettier rev: v2.4.1 hooks: - id: prettier args: [--prose-wrap=always, --print-width=88]

Might be a python package, but they've designed it to be language-agnostic, running hooks in their own virtual environments locally. For instance, they have a mirror for Prettier available.

+- repo: https://github.com/pre-commit/mirrors-prettier + rev: '' # Use the sha / tag you want to point at + hooks: + - id: prettier

You can also add InfraCost as part of the pre-commit. With pre-commit, you can define some hooks that you can easily run before you push your code. There are multiple ways to install pre-commit, and you can find examples here.

In the case of pre-commit hooks, the runtime either has to be installed manually by every user (in the case of Husky) or is handled in Python (in the case of pre-commit). Running Node.js through Python/pyenv introduces an additional layer of complexity, which can lead to issues like OpenSSL library incompatibilities.

I'm using pre-commit, follow the link to get installation instructions.

Not only can you check how well your code follows certain rules but also add auto-formatting options. This way, most inconsistencies are fixed automatically, saving time. Linters start up can be automated, for example, with pre-commit tool for python and this logic can be integrated into GitHub PR or new commits workflow. So before a new Pull Request is reviewed, it's the author who resolves any code style issues.

Today we are going to look at how to setup Black (a python code formatter) and pre-commit (a package for handling git hooks in python) to automatically format you code on commit.

# See https://pre-commit.com for more information # See https://pre-commit.com/hooks.html for more hooks repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v3.2.0 hooks: - id: trailing-whitespace - id: end-of-file-fixer - id: check-yaml - id: check-toml - id: check-added-large-files - repo: local hooks: - id: tox lint name: tox-validation entry: pdm run tox -e test,lint language: system files: ^src\/.+py$|pyproject.toml|^tests\/.+py$ types_or: [python, toml] pass_filenames: false - id: tox docs name: tox-docs language: system entry: pdm run tox -e docs types_or: [python, rst, toml] files: ^src\/.+py$|pyproject.toml|^docs\/ pass_filenames: false - repo: https://github.com/pdm-project/pdm rev: 2.10.4 # a PDM release exposing the hook hooks: - id: pdm-lock-check - repo: https://github.com/jumanjihouse/pre-commit-hooks rev: 3.0.0 hooks: - id: markdownlint

Pre-commit hooks act as the first line of defense in maintaining code quality, seamlessly integrating with linters and code formatters. They automatically execute these tools each time a developer tries to commit code to the repository, ensuring the code adheres to the project's standards. If the hooks detect issues, the commit is paused until the issues are resolved, guaranteeing that only code meeting quality standards makes it into the repository.

Pre-commit Hooks: Pre-commit is a tool that can be set up to enforce coding rules and standards before you commit your changes to your code repository. This ensures that you can't even check in (commit) code that doesn't meet your standards. This allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks.

Ah, fair enough!

On my team we use pre-commit[0] a lot. I guess I would define the history to be something like "has this commit ever been run through our pre-commit hooks?". If you rewrite history, you'll (usually) produce commits that have not been through pre-commit (and they've therefore dodged a lot of static checks that might catch code that wasn't working, at that point in time). That gives some manner of objectivity to the "history", although it does depend on each user having their pre-commit hooks activated in their local workspace.

[0]: https://pre-commit.com/