At my previous job, I was the lead frontend developer at a small startup. I was also the only frontend developer. As such, I could do basically wha...
For further actions, you may consider blocking this person and/or reporting abuse
I definitely agree that arguing over coding style is such a waste of energy in PRs. Focus on real issues.
If you ever feel like contributing to the dev.to codebase, you'll be happy to know there's prettier and pre-commit hooks care of husky. It was one of my first PRs to the dev.to repo.
github.com/thepracticaldev/dev.to/... (note the PR link is incorrect in the commit because the codebase was originally private)
Happy Coding! (Yes I just listened to your Product Hunt interview @ben 😉)
I think people are skipping the pre-commit hook, check my comment in my PR and in my last post:
What type of PR is this? (check all applicable)
Description
Add support for Github pull request via liquid tags in markdown.
{% github https://github.com/thepracticaldev/dev.to/pull/1633 %}My first time setting up a Ruby environment and actually developing in Ruby, so let me know if I should have done things differently.
I also fixed a couple of pre-commit errors, strange that the thrown errors where from parts that I didn't edit. So I assume that a lot of people skip the pre-commit check with
--no-verify. Anyways the only error I couldn't fix was this section because it would parse the html instead of showing it in the codeblock: github.com/thepracticaldev/dev.to/...Related Tickets & Documents
Closes #1760
Mobile & Desktop Screenshots/Recordings (if there are UI changes)
Added to documentation?
[optional] What gif best describes this PR or how it makes you feel?
Changelog: Github PR Liquid Tag Support
Glenn Carremans
I'm someone who obsesses over code style and I really don't want to. Prettier worked quite well to prevent me from wasting precious time formatting code.
Unfortunately, Prettier removes parentheses where it sees fit. I had to stop using it because my brain really needs them to stay put.
Any way to solve this?
Honestly, I'd just use the prettier-ignore comment to keep the parentheses. Hopefully you don't feel like you have to do this multiple times in a single file. But once in a while I think it's okay.
See prettier.io/docs/en/ignore.html
You could consider opening an issue on the prettier repo to see if others share your opinion.
Here’s the issue for that: github.com/prettier/prettier/issue...
Thanks, will surely give it another try!
I am all for consistency. I don't care much about tabs or spaces, semicolons or no semicolons, 80 or 120 character limit. All that I ask is to pick one, stick to it, and fix code that is copied and pasted in. Even better if all of that can be automated.
I think the automation is really key for me. I'll do whatever style you want as long as I don't actually have to do it. Haha.
Great article! Could you post a gist of your
.prettierrc?This is the one I use in all of my personal projects.
Our new company one differs by having printWidth be
140(that's as low as I could convince them) and "arrowParens" is "avoid". I personally like having the arrowParens but I had to let that one go.Want the
"arrowParens"? Make them use TypeScript, the type annotation of the single arg will add the parens most of the time :)How come
"trailingComma": "es5"and not"all"? Git diffs, my dude :vI will not mention the semicolon :v
OH NO, I ACCIDENTALLY MENTIONED THE SEMICOLON :v
it also makes the git commit/diffs also much more clearer.
prettier is one of those things that feels like cheating initially, and like "why can't people just care more about styling manually", and then you use it on a project and it's just so blissful and you're like "why didn't I do this sooner" 😅
I am currently using eslint + prettier + husky in my projects. It's a pretty strong combo. I really like it.