-
Notifications
You must be signed in to change notification settings - Fork 130
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
Added eslint,lint-staged and Husky #519
Conversation
@VladimirMikulic I believe you once suggested to have a linter for this project, can't recall where? So here it is. There were so many linting errors, still fixing it |
@jywarren @emilyashley @Shulammite-Aso @Shreyaa-s @NitinBhasneria please review!! |
Hi! This looks great. Will it add any extra steps we need to warn other devs of? Things to watch out for? Things we need to mention in the README, maybe? Thank you!!! |
No, we don't need to give any instruction to future devs. npx eslint command will automatically run before every commit. |
Hi, that's great. Just a few more Qs:
Thank you!! |
Nope, when a person commit the the changes with |
Cool, thanks Keshav. I'm a fan of linting -- especially if it's standard across dev environs and repos. Just curious if this plays nice with Git GUIs (i.e. Github Desktop) or if it requires developers to be using the git CLI. (sorry if this question was already addressed and I missed it) |
@emilyashley it works only with git CLI. I believe mostly use the git CLI for their work. If someone uses the Git GUI then this won't work but whenever next developer who uses the git CLI makes a commit then it would fix linting issues of previous developer as well as we are running eslint through all js files in the repository |
Cool, just noting that the more linting differs between developer environments the more linting changes can make Pull Requests and diffs harder to read. I and plenty of other developers I know use GUIs like Github Desktop or Source Tree to help manage version control and collaboration. But if the community is down with it I am. 👍 cc: @Shulammite-Aso @Shreyaa-s @NitinBhasneria |
@keshav234156 Can you resolve the conflicting files and also squash the commits. |
Hi @keshav234156 - thank you. Just to clarify, will this then be a blocker for folks using non-CLI systems? If not, I think we are OK with it, but we should note that it's optional. Apart from that i agree with @emilyashley that including linting changes in regular PRs is not ideal for readability reasons. Perhaps this means that we should also open some PRs to lint the entire codebase as a project unto itself, so that PRs don't include linting of entire files every time they're touched? But, open to ideas from either of you! Thanks @govindgoel too! |
@jywarren This will not at all be a blocker for non-CLI systems. Though I believe readibility become better if we have code is proper linted and have a proper indentation. Also, we have already been using it in Image-Sequencer and it works pretty well. |
Co-authored-by: Cess <cessmbuguar@gmail.com>
adds .vscode in .gitignore adds _SpecRunner.html in .gitignore Co-authored-by: Emily Ashley <15912063+emilyashley@users.noreply.github.com> Co-authored-by: Govind Goel <52847415+govindgoel@users.noreply.github.com> Co-authored-by: Cess <cessmbuguar@gmail.com>
Hi @keshav234156 could you please fix the conflicts ...thanks |
@jywarren @Shulammite-Aso @Shreyaa-s @NitinBhasneria Can you please help me here? Test are failing after I fixed merge-conflict. It shows |
Hi! I'm sorry, there are still some merge conflicts to resolve. Apologies on this as we're getting the next release set up, but we should be able to merge this and move forward if you can resolve these. Thank you! |
@jywarren Doing this right now |
@jywarren Done!! |
Great work here. Merged! |
🎉 🎉 |
Fixes #502
Make sure these boxes are checked before your pull request (PR) is ready to be reviewed and merged. Thanks!
grunt jasmine
fixes #0000
-style reference to original issue #@publiclab/reviewers
for help, in a comment belowIf tests do fail, click on the red
X
to learn why by reading the logs.Please be sure you've reviewed our contribution guidelines at https://publiclab.org/contributing-to-public-lab-software
We have a loose schedule of reviewing and pulling in changes every Tuesday and Friday, and publishing changes on Fridays.
Thanks!