Run Prettier in CI, NOT as an editor plugin
Вставка
- Опубліковано 13 кві 2020
- 💛 Follow on Twitch and support by becoming a Subscriber
We record the show live Mondays 7 AM PT
/ funfunfunction
💛 Fun Fun Forum
Private discussion forum with other viewers in between shows. www.funfunforum.com. Available to patron members, become one at / funfunfunction
💛 mpj on Twitter
/ mpjme
💛 CircleCI (Show sponsor)
Robust and sleek Docker-based Continuous Integration as a service. I used CircleCI prior to them becoming a sponsor and I love that their free tier is powerful enough for small personal projects, even if they are private. Use this link when you sign up to let them know you came from here:
circleci.funfunfunction.com
💛 FUN FUN FUNCTION
Since 2015, Fun Fun Function (FFF) is one of the longest running weekly UA-cam shows on programming 🏅 thanks to its consistency and quality reaching 200,000+ developers.
🤦♂️ The Failing Together concept is what makes FFF unique. Most coding content out there focus on step-by-step tutorials. We think tutorials are too far removed from what everyday development is like. Instead, FFF has created a completely new learning environment where we grow from failure, by solving problems while intensively interacting with a live audience.
Tutorials try to solve a problem. Failing Together makes you grow as a developer and coworker.
📹 Each show is recorded live on Twitch in a 2-hour livestream on Mondays. The host, assisted by the audience, is tasked to complete a programming challenge by an expert guest. Like in the real world, we often fail, and learn from it. This, of course, reflects what the audience identifies with, and is one of the most praised aspects of the show.
⏯ On Fridays, an edited version of the show is adapted for and published on UA-cam.
Content Topics revolve around: JavaScript, Functional Programming, Software Architecture, Quality Processes, Developer Career and Health, Team Collaboration, Software Development, Project Management - Наука та технологія
Format on Save, never looked back
Go got me into this, Prettier kept me there.
No idea how you can write code without style fix. I write junk quickly, hit save and it gets pretty...
I write the junk and hit save. I then focus solving the problem, and then I run Prettier and it gets pretty.
@@funfunfunction But how can you focus on the problem when the code looks like junk and indents are off and everything _looks_ wrong?
As long as the code in the finished pull request follows the standards, any way that works for you is fine of course; but I find the amount of not caring I can do with an automatic, on save formatter like prettier is a big boost to my productivity. I recommend everyone should try it. It's a bit weird at first seeing the code you just wrote transform, but you get used to it.
If you force yourself to write pretty code; you would have no problems and you would not need plugins after getting used to it. I know it is easier to just let the plugin do everything but letting the plugin and not learning anything from this is not good in my opinion. This makes you unable to work outside of your editor but I can do all my work on almost any editor with no plugins if I ever need to.
I felt the same. LOVE to just bang out some code and then let it be structured when I'm waiting for the tests to run
@@menfie Sorry, but to all but the most junior developers, manually maintaining style is objectively a waste of time unless it helps you on an individual level to stay focused and productive. No mid-level dev has a problem writing pretty code and managing indentation, but it's overhead work. "It makes you unable to work outside of your editor" seems truly like a made-up problem to me unless maybe you're a devops engineer or someone who spends a ton of time in terminals. I have been "in my editor" for essentially 4 years, why would you optimize your workflow for an edge case that won't apply to you most of the time? The productivity gains of offloading basic code formatting to Prettier, I'm sure, easily eclipses any benefit from being editor-agnostic for 95% of devs. This might be the false consensus effect but I can't see how it's untrue.
I see your point for the linters, but tools like Prettier are fully automatic, they require no manual intervention.
I feel that they ease my work when quickly prototyping and I can write without caring for style and prettier makes my mess more readable, which in turns allows me to understand it better and modify it with ease a minute later.
I know that the Prettier in-editor plugin is fully automatic, I've used it extensively. The problem is not that - the problem is that I often find myself distracted by styling and code organising at a too early stage, just like I find myself concerned with premature optimisation or premature generalisation. My coding style is to focus on one thing at a time, and the first thing being getting the tests required to pass, and deferring things like code organisation, style, naming etc. Your mileage is different based on personality type, of course, and if things jumping around in the editor doesn't trigger you to start thinking about style (remember that Prettier only does a very small subset of what code styling actually is), then all the power to you - I cannot deal with it while I'm coding and become distracted.
@@funfunfunction It's interesting what different people find distracting. I get easily confused and distracted by code that isn't formatted (especially in regards to indentation and functions with 4+ parameters or components with 4+ props), since it offers a way to visually deduce scope and helps me navigate around a bit more smoothly. Since I work very incrementally, the "jumping" is minimized so it works for me. Thanks for always sharing new perspectives!
Hair tutorial coming soon?
😂
In the Netherlands all barbershops are closed until further notice, and it's almost forbidden to DIY your own hair, out of solidarity to the barbershop branch hoping to be able to open again soon... (Our government calls it 'The Intelligent Lock Down', yep!)
Never thought about that before, very interesting !
I guess people's minds really work very differently, because I'm barely able to empathize with your viewpoint here. How could a few lines moving around when you hit save distract you? I've never had that problem.
I get that that's your personal experience, and I didn't actually have a problem with the content of the video, but I think you'll find that your perspective on this is, maybe not unique to you, but quite rare. So it's kind of weird how authoritative your video title is. "Run prettier in ci, NOT as an editor plugin"? No, screw that, it should be called "why I'm running it in CI but it's fine if you like to run it on save"
You cant write a UA-cam title like that and still get views, but I'll be a bit more mindful about how I could stress that this is my perspective and how I work.
I run it on save. Never red.
Where is the good, old FFF video intro? :C
Never got around to making a new one
Nice stuff as always Mattias! Thanks for everything you're doing!
What do you mean by putting marker in your stream?
Im with you on running it later. I used to do it the other way around, but after some thinking and seeing your older video about it I realized what is faster. You mentioned lots of commits, do you squash them after?
I tend to squash commits as the final step when code review is done, sometimes before. It's best not to have tons and tons of commits in the main repo with tiny changes.
Might I suggest a video creating a github action to use prettier on a project? I'd love to see that personally since I find github actions quite confusing!
What are your thoughts on "Go," where "Format on Save" is the convention? Do you find it helpful or distracting? (Most people seem to like or be neutral about it, interested in arguments against gofmt)
I do like to lint while developing, just because I think it reads easier and I'm used to it. I agree though that "all the red" can be distracting and I often notice when my pair isn't that used to my linter config, that they seem distracted by it and focus a lot on fixing the linting.
I really enjoy watching how Prettier is modifying my code after I saved the file. It's some kind of... magic. You write your code in your silly messy manner and then the older brother is cleaning up for you. It's wonderful.
I run prettier from my editor but have a separate keybind from ctrl+s(ave).
That's a good balance of having the utility of autoformat make this looks good (works if you select only part of code !)
I use it often to check if I need extra paren or not, or ensure that the syntax is valid without having to test !
I agree with you MPJ I try to write as clean as I can from the beginning and get the feature/bug fixed w/out having to worry about my text being altered by autosave formatting etc. I want to dictate how my code is and I've found that I don't always agree with Prettier at that particular moment in my process.
Problem is coming when someone is using Prettier and other people in the project not. So those people PR will usually have more changes ( cause their editor will reformat whole file ). So to avoid those issues I am always adding format and lint scripts to pre-commit hook.
Just to be clear here because 100000 people seem to miss that part of the video AND the bloody title: Prettier (and eslint) should of course be in CI.
@@funfunfunction I can imagine when we run prettier during merge, but what about the case when we will run prettier scripts on each push to origin? If we will not run prettier each commit our git history will be a little more "dirty". Pre-commit is solving it perfectly. Prettier and Eslint scripts are not very long, so we will get faster feedback when something wants wrong. Only as a confirmation always we should run Eslint on CI, just I am only not sure about prettier :)
No, I did not miss it, I just do not agree :D ( only about prettier )
And what do you think about running Prettier on pre-commit or even pre-push? There is already a great tool pre-commit.com to allow such things.
You couldn't finish a 3-minute video before making a comment?
@@cool_scatter I've finished, but I haven't heard mentioning about this tool.
As scatter says, I say this in the video, on pre-commit is better, but I tend to do it defer it even further, to pre-PR. My rationale is that I tend to want to commit on every test I write that goes to green, and I often want to implement multiple tests before I focus on the organisation and styling of my code. Partially because I want to focus on problem solving and end user value first, but also because I find that refactoring and styling that often leads to me styling and refactoring a lot of code that just goes away - i.e. doing organisation and styling equivalent of premature optimisation.
Also when working on a team, all having prettier reduces way too much merge conflicts for spaces, semicolons, etc..
Please read the first four words of the title of the video before commenting :)
I feel like if I didn't directly see the changes something like prettier makes to my code, it would take me longer to familiarize myself with that file when I need to update it.
I think in the short-term this would increase my productivity but in the long run it would be more harmful than it's worth. Might be unique to my team setup and workflow, though
I love running prettier on save personally
I would love to see a video on SOLID / OOP. Although I think that might not be your kind of thing?
Yeah, I'm very past OOP and it's not a paradigm I'm a fan of, or want to encourage - it's much more important to teach the programming community about functional programming, which is still vastly misunderstood and OOP vastly overused. OOP has its place, but it doesn't need more advocates.
I like to use prettier in the editor, I actually use prettier in eslint with auto fix on save. I basically type some ugly code fast and save the file to make it pretty :)
I get your point about defering concerns, but frankly I find having eslint/prettier in IDE actually helpful even in the early stage, it can catch mistakes I would otherwise overlook. Cleaned style also helps, improves readability and efficiency as a result, even if I scribble a draft proof of concept just for myself. However, have to admit I don't always fix all 100% of rules until I'm really done with the MR.
Just to be clear this is about Prettier and styling, not static analysis of logic errors. eslint (with styling-related rules removed, as prettier now has that responsibility) is super valuable to have in-editor on save.
@@funfunfunction Ah ok, so you'd still use logic linters in IDE (or on save), but not code styling linters. Btw. I like the idea of that automatic on save corrections and I don't like at the same time :) it's convenient for sure, but I'm worried it can "spoil" developers to write messy code (because some tool would automtically fix the code for them anyway), whereas highlighting errors in IDE can better serve the purpose of teaching to write cleaner code by hand. Also one can feel lack of control when code is automatically changed by some external process. But either way, in the end it's a matter of habbit I guess.
Why not lint on save?
This is about Prettier. I use eslint (with non-styling rules disabled) because that helps logic errors which are relevant to implementing my feature.
Also, it's very easy to accidentally leak a localised (accidental or temporary) config change into the repo
Note the first four words of the title :)
DOPE hair
Thanks!
Leaving it to CI makes it so that CI makes "worthless" commits. Doing it during pre-commit doesn't make extra commits.
Interesting thoughts! From working in a largeish company I disagree for one reason: git blame. If someone else than you run prettier, then the git history can get confusing. So pre-commit or prettier on save works better imo.
I understand what you're saying about breaking flow, but personally I think format on save feels nice: a short "konstpaus", and the feeling of being helped/supported by your environment
In case you missed it in the video, and the first four words of the title of the video, I advocate running Prettier in CI.
@@funfunfunction yeah I know, that's what I meant by "someone else than you" if you run prettier in CI, you mean the CI should add and commit the prettier'd result right? Then your git history will show a lot of lines as being developed by your CI user
In most of the teams I've been in the biggest problem was having ESlint report any styling related stuff. This is way too common imo. Not only does it distract, but everyone will become conditioned to ignore the linter.
Best way to deal with it imo is to disable all ESlint rules regarding styling. Then motivate everyone to use Prettier on save, as this will also help to highlight the semantics of your code (stuff like misinterpreted parenthesis or missing semis before a line that starts with a bracket or parens).
Not having a prettier precommit hook is a big no in my experience, as your commit history will undoubtedly be containing messy unformatted code. Try using git blame, disect or the gitlens plugin in a project that doesn't have precommit hooks, it's not pretty (pun intended). If you use the pretty-quick module, running prettier as a precommit hook is super fast and it never fails unless you have a syntax error, in which case you shouldn't be comitting anyway.
I find the biggest contribution of Prettier is to get styling out of eslint, and have it focused on well, linting, and that is something that people will respect way more than whomever got in before them in the organisation to put their preferences in the style rules. I really do agree in disabling all eslint styles and deferring that to Prettier, which is the great equalizer. :)
You do also make a great point about git history, one of the first non-emotional or incorrect points made in this comment field - thanks, I'll keep that drawback in mind.
@@funfunfunction Theres still the Prettierrc to disagree about, hahaha, but at least it's much more managable.
I've got a PR up for the VScode ESlint plugin btw thats a milestone for version 2.2.0, that hides any reported errors/warnings that would be automatically fixed anyway. At least when someone's in a project where they don't have control over the setup they can mitigate the problem that way. Hope they release it soon.
I see you like a non-semi style, I personally love prettier on save for that, because I still haven't built the habit of prefixing lines starting with [ or (, and it confronts you with that quite brutally 😃
why not run it as a githook?
Why not both?
This is literally the only question this video explains :D
I think you are a bit outdated on this topic.
Working without prettier installed will actually make you waste a lot of time on indenting and making the code look clear.
Prettier just fix the code for you and make it look nice, there’s no implicit rules you have to follow like eslint.
About eslint, I agree, no need in the code editor, only in CI.
The point is that you're typing, press save, and everything moves on your page. For some people that's a big distraction - especially if you're working on a complex piece of code and you want all your attention on that.
It's not a case of being outdated, it's about setting up a workflow that helps you get from A to B, while still getting all the benefits of a shared code style.
F Stokes understands what I mean here and explains pretty well. To be clear: I intentionally avoid spending time on styling AT ALL while coding. I defer refactoring, removing duplication, proper naming, styling, etc. until late in the process - it's the commits that come last in the PR for me. Leaving Prettier until that time helps me focus on that process.
@@funfunfunction Fair enough! I think we have to agree that everyone has a different way to get in to the flow. Even if sometimes doesn't make sense to others :D
Thanks for the great content!
Not sure I understand. How does a pre-commit hook distract you? It's not anything you should really notice.
The whole idea of prettier is that you don't EVER need to think about formatting/styling.
Ever since starting to use it, formatting has disappeared from my list of things to think about when coding.
It distracts me from getting functionality working and forced me to context switch. I.e. my tasks become writing test, writing test, writing test, instead of writing test, context switch, styling, context switch, writing test, context switch, styling, writing test.
I understand that the whole idea of Prettier is to not make you think about styling, but it makes me think about styling when it is in the middle of the work process. I can't believe that its so controversial that I want to push styling into the end of my work session. It's no more strange than focusing on cooking and doing the dishes once you've completed the dish.
@@funfunfunction just trying to understand :)
I'm not saying it's controversial I just find it strange that you find pre-commit hooks distracting because they don't require any effort from the dev. To change your analogy to make it more accurate to how I personally see it - having a pre-commit hook is like having all the dishes automatically washed for you by someone else while you are focused on cooking. So you never need to context switch to "styling" at any point of your workflow.
But I can see there's something in the way you think/work that is different and that's fine! We are all different people :)
I use eslint with styling enforced so it warns me about any issue or junk I wrote in my code
well, i run prettier on both, on local since it helps my development process and in CI essentially for code style consistency. it works out pretty well