Run pre-commit (eslint, prettier) in both docker & local
See original GitHub issueWe use husky to run eslint before committing but this doesn’t work when running docker. Warning:
Can't find Husky, skipping pre-commit hook
You can reinstall it using 'npm install husky --save-dev' or delete this hook
We want this to work for people working with and without docker. Here is one potential resolution but it might work only for docker: https://github.com/MadeInHaus/react-starter/pull/30/files
EDIT: The above linked example is also not appropriate because we have multiple npm projects.
Needs to be added to both client/package.json
& backend/package.json
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (1 by maintainers)
Top Results From Across the Web
Pre-commit Hook - Prettier
You can use Prettier with a pre-commit tool. This can re-format your files that are marked as “staged” via `git add` before you...
Read more >Writing an ESLint Hook for Pre-Commit | Python in Plain English
First, configure your ESLint set up locally. There's a good guide on this here; in short, you can just run npx eslint --init...
Read more >Setup eslint/prettier on docker + host · Issue #1 - GitHub
This issue aims to describe how if you setup docker on a fullstack project, you may loose some developer experience like in-editor linting...
Read more >Angular with Eslint, Prettier, husky | by Stavros Droutsas
In this article, we will create a new Angular project and we will configure eslint, prettier and husky. Linters and git hooks are...
Read more >Automatically format and lint code with pre-commit - Interrupt
How to use pre-commit for automated linting, formatting, and styling firmware code by using Python, clang-format, clang-tidy, and prettier.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think for the short-term we can just follow this method as @joshmorel mentioned as we will likely break up frontend and backend into separate repos at some point. They will likely be independently deployable and independently scalable as well since as @robinv85 mentioned there are more frontend clients/consumers of the backend API than just the React web frontend, and as it’s currently set up, the other clients would have to connect directly to the web frontend container to be proxied to the backend for any API call it needs to make. So this would put unnecessary strain on the web frontend container.
As for Docker Compose, it’s obviously going to be a bit more complicated with services being in separate repos, but I think that can be easy to solve if we create a shell/parent repo that references the other repos with git submodules. Symbolic linking is also another option. We can then run the Cypress e2e tests from this repo.
Thanks @joshmorel