Skip to content

Check formatting and eslint in CI + review pre-commit hook #210

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 of 2 tasks
gndelia opened this issue Aug 5, 2020 · 9 comments
Closed
1 of 2 tasks

Check formatting and eslint in CI + review pre-commit hook #210

gndelia opened this issue Aug 5, 2020 · 9 comments
Assignees
Labels
chore Changes that affect the build system, CI config or other changes that don't modify src/test files released on @beta released

Comments

@gndelia
Copy link
Collaborator

gndelia commented Aug 5, 2020

There have been a few PRs that had style modifications in files or Readme examples of code that were no actual changes as part of the PR that was being opened.

We are not enforcing our defined styling enough (I think it's only run in a pre-commit hook) which can be skipped. This ticket is to

  • Review the pre-commit hook to ensure it is actually working, and (except for manual skip by the dev) that it always runs when committing new code

  • Update our CI process to verify the code to be merged is following the eslint and prettier rules, preventing new code from being merged if it does not follow our style guide

@gndelia gndelia added the chore Changes that affect the build system, CI config or other changes that don't modify src/test files label Aug 5, 2020
@gndelia gndelia changed the title Check formatting and eslint in CI + reviewing pre-commit hook Check formatting and eslint in CI + review pre-commit hook Aug 5, 2020
@Belco90
Copy link
Member

Belco90 commented Aug 5, 2020

I can see already an issue: .lintstagedrc is trying to format .js files, which we forgot to update to include .ts files when we moved the plugin to TS!

Another issue we might have: pre-commit hook in .huskyrc is running tests and then running lint-stage command. This caused me issues in the past as was losing the modified files context after the 1st command was called. Instead, the corresponding config to avoid this would be:

.huskyrc

{
  "hooks": {
    "pre-commit": "lint-staged", // <-- we just run lint-staged here to make sure we don't lose the staged files context
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
}

.lintstagedrc

{
  "*.{js,ts}":[
    "eslint --fix", // <-- first we lint staged files
    "prettier --write", // <-- then we format them
    "jest --findRelatedTests", // <-- now we run tests related to modified files, similar to jest watch mode
    "git add" // <-- git add is still needed in the lint-staged version we use but has been removed recently so we can get rid of it in the future
  ],
  "*.md": ["prettier --write", "git add"]
}

@Belco90
Copy link
Member

Belco90 commented Aug 5, 2020

Note that I'm not reusing any of our scripts from package.json. This is on purpose. lint-staged allow to run your custom npm scripts but you need to pass that final -- so the script can receive the list of modified files. I prefer to stick to hardcoded eslint, prettier and jest commands as I had problems too by forgetting those final dashes in some of them.

@gndelia
Copy link
Collaborator Author

gndelia commented Aug 5, 2020

git add is still needed in the lint-staged version we use but has been removed recently so we can get rid of it in the future

what about updating the lint-staged version? It's a dev dependency. Or is it anything that might block us?

@Belco90
Copy link
Member

Belco90 commented Aug 5, 2020

Updating both husky and lint-staged would be great actually!

@gndelia
Copy link
Collaborator Author

gndelia commented Aug 5, 2020

ok I think I can probably check it in the incoming days. I'm taking it

@gndelia gndelia self-assigned this Aug 5, 2020
@Belco90
Copy link
Member

Belco90 commented Aug 15, 2020

I've seen the current repo has lot of ESLint errors, so maybe we can do this over v4 to do this over next changes?

@gndelia
Copy link
Collaborator Author

gndelia commented Aug 15, 2020

Do you mean to apply the changes directly on v4? Sure I can do that.

@github-actions
Copy link

🎉 This issue has been resolved in version 4.0.0-beta.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@github-actions
Copy link

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Changes that affect the build system, CI config or other changes that don't modify src/test files released on @beta released
Projects
None yet
2 participants