Some influncer came with "some experience" and just "pretends" that anything that worked in last 20 years is not working anymore because of some personal opinion. For example unit testing. Just please stop it. Saw those videos and dude just cant answer basic questions why it is not a good idea, just goes around talking about other things and trying to sound like he did answered. Too much bullshiting.
The biggest confusion that I’ve seen around this topic is when you include VSCode into the mix. Is not always clear who’s formatting my code. The vscode extension formatting on save or my precommit hook.
Technically pre-commit hook and extension should derive the state from the same config, so it shouldn't matter in the end. And Prettier doesn't use folder config inheritance nonsense ESLint does, so it's easier to set up and test.
@@ra2enjoyer708 genuinely curious, why even use the extension then when u can have prettier set up as a pre-commit hook which ensures everyone developing the project will have the same formatting?
Theo I've only recently found your channel but man am I enamoured (by your content)! You make the best devs videos that aren't just "tutorial/intro to technology" where you gloss over "advanced" topics and only cover superficial and basic level concepts. You truly make videos that devs want to watch, covering a broad range of topics, making informed arguments, and overall just being a top tier dev (uploadthing). Looking forward to the rest of your great work.
These days we expect the tools to be intuitive. They should just remove the styling functionality in eslint. The reality is that it isn’t that most developers think they’re better than open source maintainers… It’s that they never think about the maintainers’ existence at all. Opensource has always had an aspect of putting what you want to have out there, out in the world. But you're doing it without an expectation that the users act like customers or fans.
Great video, only thing I don't agree with is not having a prettier config... If you share a repo with even a small team the likelihood that someone has changed their default prettier config is pretty high. I do believe the defaults are fine but setting them in a config so it overrides each team member personal config is the play for me
@@im_arsnl awful take lmao. If that was true there would be 0 reason for the prettier config to even exist... In my experience prettier is there to help straight out of the box with the defaults, but in react with ts I like increasing the printWidth just so I don't have a generic component function spread into 3 lines. It's just straight up personal preference because it compiles to the same code at the end of the day.
I think a good reason for having a prettier config is that it pins down all the defaults or whatever configs you like. That way if the prettier team changes their mind on what a given config value’s default should be, you can still stay witht the same formatting as you had before without creating a PR where 7000 files have changed.
I agree both a linter and formatter have their own use cases. However with prettier I often find it to make the code unreadable when the printwidth is exceeded. I have now used eslint only for a few projects and the only thing I encounter is having to decide when to break a line of code into multiple lines. Adding full Prettier for that for me feels overkill
This is pretty late, but I'm glad to see other people who also think this! Prettier absolutely kills readability. I trust myself and my team to know when to add line breaks for readability, an algorithm will always do worse. I even tried BiomeJS, the new formatter on the block, but it has the same problem. I'm sticking with ESLint and ESLint stylistic for the future UNTIL someone makes a formatter that does NOT add line breaks (ESLint Stylistic basically is that already though)
While it would be a breaking change, I feel like ESLint would be doing themselves a big favour if they just removed the ability to have stylistic rules in ESLint altogether. They could have a non-breaking change that just adds a warning message to the output saying, please don't use eslint-plugin-prettier and link to that page you showed, or better yet this video.
yeah. same thought. why is it possible to add simple stylistic rules but also warn everybody "hey please just lint. dont style with eslint". so yeah why is it even possible?! :D
The reason I do Prettier via ESLint is because that's the way I've managed to make things work in a consistent and predictable manner. I hit save in VS Code, and it does both Prettier formatting, and ESLint auto-fixes. If I need to do it from the command-line, it's just a single command I need to run. To check things on the CI server, again, just a single command needs to run. It's maybe a little bit slower, but it works, and I don't have to think about it anymore. Can you make a quick video on how you would set up Prettier and ESLint in a simple project, in a way that it works seamlessly via VS Code and is easy to integrate in a CI build? I would very much like to learn how to make our setup more performant if that's possible, which it seems like it is.
@Svish85 google 'xojs', it's basically an ESLint + Prettier (optional) wrapper with sensible default and offers an all-in-one command and a VSC ext for Prettier-then-ESLint
the only thing I format with ESLint are my imports, because prettier doesn't care at all about some details I prefer and the plugin by trivago does weird stuff with the AST of prettier, so I'd rather use the ESLint plugin that is guaranteed to work better and basically does the same thing.
One thing that's annoying with Prettier is that ‘trailingComma’ is not set to ‘all’ by default. Trailing commas are really really good for versioning systems like Git, so you always gotta have a prettierrc to enable it. I also like using JSDoc Prettier plugin (it's frankly is a must if you are working with types via JSDoc), wish it would just be included by default. But then, they also completely ignored the request to use tabs by default, which is accessibility concern...
Not sure why UA-cam decided to remove my comment. But to Theo: no, they were going to consider making tabs a default in version 3, but it has been since moved to version 4, so I doubt it happens any time soon.
This and Josh's talk are honestly great value. Linting and prettier have always been boring tooling I've refused to invest time into learning or caring about. Being able to grok how these 2 tools interop and when was a huge help for me. Keep on keeping on with the great content!
I use eslint-plugin-prettier in my codebases, and it has always worked nicely for me. It's convenient being able to do an eslint autofix and have all the fixable lint issues and formatting errors taken care of with one command. I also like the fact that my formatting issues show up in my code through the eslint extension. Though, it's good to know that if my formatting ever becomes slow then this might be why.
I was always expecting that Prettier just uses Eslint in the background, and in that case, it would be better to add prettier to Eslint. But now i am confusing, and will dive into the prettier code to check how it really works.
Personally i just had really bad experiences with Prettier (Vue Project. That was about >1 year ago. I've spent multiple hours trying to configure prettier for vue templates but it was just annoying and painful. i could give it another try tho)
They should make the docs better, i want to see in 30 seconds what to install and what not to install. They even put link tags around things they recommended not to install thats confusing lol. We have colors for a reason. The prettier team and eslint team really should work together to make it more clear if so many devs don’t understand what to do. And not every dev is native English which makes it even harder.
I got a PR rejected to a eslint plugin repo because I failed to understand this exact point. I pushed to use prettier in our team, and my life has been better since
I'm def not pretending to know better than the lib maintainers, it's just confusing to me that eslint supports formatting rules, can apply the formatting automatically, but then they are like "hey don't you dare using eslint for formatting!!1". Why do they build it in in the first place then? Well okay I believe you and will install prettier now ...
Good points on most except for the point about config. This might work on personal projects, but if you are working with multiple developers on a production application you want to have a config file with the define set of rules for that project and also prettier actually installed on the project so that everyone is using the same version of prettier on the project. Nine times out of ten it wont be a problem, but it could save a lot of headache if someone has a weird configured IDE.
My thoughts are if the linters don’t want you to style your code with them then they should just remove the stylist rules module from the linter. If you cut the head off the snake so speak, it can’t bite you. If you remove the ability to restyle, it can’t interfere with formatters.
There's nothing worse than having a linter tell you that your formatting is wrong. I don't want to know... I just want you to fix it. Formatting lint errors are PURE noise.
Same thing with the Tailwind ESLint plugin, which has formatting enabled by default for some reason. The worst part is that the third party ESLint plugin conflicts with the official Tailwind prettier plugin. Ugh!
I use ESLint to enforce prettier rules because I dont wanna manually fix linting issues which are very mechanically auto-fixable, while also formatting my code by Prettier standards. I'll take it being slower because it won't be as slow as me going in and fixing stuff manually. For example, I use eslint-plugin-tailwindcss instead of the prettier plugin for tailwindcss (some stupid thing caused my code to be "formatted" very slowly, around 10 seconds for each formatting. I was told it was this plugin. I switched it, and the slowdown went away). Now the plugin tells me the tailwind class order. I don't wanna fix it if the computer can do it hehe. Prettier can't enforce auto fixable linting errors but ESLint can enforce formatting standards, however slow-er. My projects are not nearly large enough to be affected significantly by the slowdown so it works in my case (if that makes a difference).
Interesting, I usually only use the default ESLint and prettier settings in my VSCode because I just want my code to look consistent and not have to think about some crazy manual configurations....
Our team configures every project with ESLint autofix and Prettier on save. There is no performance issue, and I don't understand any argument why you would want to run the linter separately. I appreciate that the developers of these tools might not intend it to work like this, but when configuring our editors (usually VSCode, sometimes a vim, emacs, etc) having a single config that does both greatly improves consistency.
I can never get these two to work together properly. When both are active in a project, I always got competition between the two where I'd save, and one would undo formatting that the other did. So I just get rid of prettier and format with eslint. It may be slow, but it works and it's fast enough for me.
there is a package called "eslint-config-wesbos" and it combines the two, I didn't know about these 2 tools until wes bos and I always used his package to get them both to behave, but after this video I am weighing my options...I like that I can list and beautify my code at the same time
Nice talk, but without a good example of configuration, it's just a talk. Including a detailed pipeline for build and deployment would make it more effective.
I appreciate the point but have to work on code bases where all the eslint rules are actually formatting rules so you’re kind of stuck in between a rock and a hard place. Maybe I’ll play this to make my point at the next development sync 😅
What am I doing wrong when my tailwind css prettier auto class sorting works sometimes and sometimes it doesn’t work, this mainly happens when I’m using cva and tv functions. Do others experience on/off sorting functionality?
Last linter I've used was TSLint, the only ready to use linter. ESlint it's just bunch of rules that want to make Typescript less Typescript, and it changes every day!!, one day I woke up, updated some dependencies and half of the project was red, how can you say they know better when they can't even agree about which hand are they gonna use to wipe their behinds with the next day. It's a nightmare every time I try it, I always disabled it. Bring back TSlint!!!
Thanks for making me/us aware of dprint, need to look into it. By the way, there is also this tool called Rome, which is basically a linter and formatter combined into one. Not sure if I am ready to replace ESLint with it yet, cause I have a bucketload of rules that are probably missing since it's still in development, but maybe one day it can and you won't have to make videos like these anymore :)
Attempt #3 at commenting, I think youtube auto-removes my comments when I reply to you because you have an URL in your username :D But I wanted to ask what makes you say that? I checked their github repository and it seems very much in active development with like 9 new releases in the past month.
@@dechobarca Rome did the equivalent of what Deno did initially in runtime world: Deno ignored the whole eco-system of npm packages by not supporting them; Rome does not have a way to use exciting or custom ESLint rules and only add support for rules they think needed. There're other issues with it, but this is the most prominent one in my book.
@@moshyfawn oh okay, thanks a lot for the explanation. That's very unfortunate, migration would be an absolute nightmare now that I think about it, especially for people that maintain a big list of carefully curated rules. Maybe someone makes a tool for migrations, but if they are stubborn in supporting what ESLint supports then I don't see this going anywhere sadly :|
@@dechobarca oh man that checks out actually, good catch Re: Rome being dead, they significantly downsized the team mid rewrite and have shifted focus significantly. I could be flipped but like they went from the HOTTEST thing to one blog post a year 🤷♂️
I use only ESLint for my project, the only problem I have is a bug on VSCode configuration, depending on the config, sometimes when I press CTRL + S it applies the lining and removes again if I press the shortcut again, and it keep applying and removing in a loop, it's a bit weird,, I think it's related to the config "editor.formatOnSave"
Рік тому
wouldn't it makes sense to have 1 tool you can either run to format or to lint? If you could run eslint either with only fixing formatting or with doing linting i can imagen it can be just as fast on the formatting part?
Nah, this is an old video, but I absolutely hate prettier and formatters in general. For some reason, there is no way to disable the line width option in any formatter, and it forces your code have line breaks in places you don't want them to. A lot of times, it makes things look worse. As a dev, I trust myself and my team to know when to add a new line and when to keep things on the same line for readability. Following an algorithm will not give you the best readability, and I always get worse looking code no matter how much I try to customize the line width option. Too little or too high gives problems in different places. I still use ESLint for formatting because the newer versions work instantly and actually just enforce style rules without ADDING RANDOM LINE BREAKS where I don't want them lol. Also, the new ESLint separates style rules into a separate package called ESLint stylistic. It's nice.
Рік тому
What was the rust formatter he mentioned? I cant find it
4:23 People will not listen .. because they think better. This is often a problem of people are being told but not shown replicable proof or reminded of the steps to reproduce the proof. Then there's also overcome peoples bias from muscle memory or willingness to change config files. Configs they may already have heavily invested their opinion into , but never tested and proof would wipe that investment. Sigh.
If ESLint is not meant to be a formatter, then why does it have formatting rules? Also, Prettier is not flexible. If you don't like else if statements on the same line as a closing curly brace, you're out of luck. I'm sorry, but there's no such thing as a one size fits all formatter. If your formatting tool can't be configured to fit different styles, and you don't like its default style, then it is inferior. For me and my team Prettier is inferior to ESLint for formatting
Personally, I am using both ESLint and Prettier as formatting tools. I think that's not too wrong with that. I am using eslint-plugin-perfectionist, it can cover what Prettier can't do
I grew to dislike prettier with passion. Just because some people can't grow up and organize themselves but spend ungodly amount of time picking "the right style" shouldn't hinder my ability to make my own decissions. The "opinionated" part is basically treating us like kids instead of adults and making deccissions for us. Prettier tries to solve several problems at once - format your code AND keep the codebase consistent, without wondering if it should. IMO for superior approach would be a future-reach, customizable, on-demand formatter on the IDE side, so that everyone can work in their preferred style, but opinionated and uniform formatter when pushing to remote to maintain diffs minimal and uniform. No more "bickering" about the code style - you get what you want in your IDE's but the repo is consistent at the same time. Ultimately the style doesn't matter for the semantics... The number of times Prettier made code easier to read was roughly equal to when it made it harder and annoying.
I don't really mind if it's taking 2 seconds longer than it should be but more than 2 secs are definitely bad. I wish we got a video comparing prettier eslint and the bare prettier one.
Me configuring typescript, vue, vscode extensions, pinia, router, vite, (previously babel, webpack), tsx, dotenv, tailwind, playwright, vitest, eslint, prettier... It's good to hear the complexity of the last two things are necessary. Joke. I used bun for several months.
It would be great to have a more streamlined TS/JS ecosystem that eliminates the need for tools like prettier, linter, and ts configs. Having to learn and configure these tools can feel like a waste of time. 😿
Hi Theo, ESLint 9.0.0 is out (breaking changes). If you have time/will, please make a video on ESLint and Prettier in a node.js typescript project (e.g. Nest.js). It would be really appreciated. Thanks in advance.
The problem is so many framework CLI's set it up wrong in the first place: they enable the eslint prettier-plugin. The biggest problem with this plugin is now you have red squiggles for any formatting errors. This accomplishes the opposite of what prettier sets out to do: allowing you to completely ignore formatting.
or yellow squiggles, easily distinguishable from linter errors? An no, if prettier just allowed a team of devs to "just ignore formatting" it would be terrible. It's real use is to keep the team working to the same standards, and that can be better achieved (and taught) with code hinting.
Yeah.. nope.. In the end these are tools and if a tool doesn’t do what I want, it is slowing me down. I would use Prettier if it wasn’t so (over) opinionated. I want to decide when I keep code on one line or move it to the next. Not based on some arbitrary integer value. This to me is really broken in Prettier and you’ll have a hard time convincing me it isn’t 🎉
I'm not a fan of prettier. I prefer to just let people on my team code how they want and avoid the annoying diffs of space adjustments and fille file reformats. Would rather just see the diff that reveals the work actually done, then prior to merge, run the linter and move on with my life.
"This is meant to do this, that is meant to do that" --- it's not an argument, it's a definition (arguably a wrong one, as formatting is part of code quality) "So many people think they're smarter than OSS people" --- it's not an argument, it's a statement (one which doesn't make sense). Prettier is intentionally opinionated, so what happens if I want to adjust it with the help of eslint? prettier-eslint is a good answer to me, for which the Notes on the prettier webpage mentioning the downsides - don't make sense as well. I'm still waiting for the arguments.
It has to do multiple passes, it’s significantly slower, and it fundamentally misunderstands the role of a linter. You can be stubborn all you want to be. We’re gonna focus on engineering here :)
@@t3dotgg You didn't answer my use case, which is pretty valid. I've been working with a code base which was dominated by long, nested if-else blocks. (Oh, it is OSS, so I'm in the club now?) For those, "stroustrup" if-style made the code much, much readable. Prettier doesn't have an option for that, eslint does. "multiple passes" - who cares, it's a technical detail. You're putting milliseconds above code readability? "stubborn", "misunderstands" etc. - blah blah, labels...
@@t3dotgg I took over the code base of 'smashtest' as maintainer and turned it into typescript. It's OOP and stroustrup style. Prettier made it worse not allowing stroustrup. I don't know what you mean by "my" codebase, and I don't get how nitpicking on milliseconds adds to the conversation, but I didn't feel like lint speed was a problem in my workflow. Unless you have monster-size source files, it shouldn't be a problem, right?
While the performance and complexity you mention is certainly there, I never ran into major issues with that in eslint. I'd rather use a single tool with the IDEs built-in formatter rules that can be synchronized fairly easily than run yet another tool that lacks on options. The biggest pain point for me in Prettier is how they intentionally limit your ruleset based on their opinion instead of being a tool that can facilitate any opinions. This kind of elimination of tools saves a lot of time with the automation pipelines even if in theory slower, but in reality there is many other steps involved like cloning the repo and spawning up a new container that takes away the actual speed advantage.
Since I started watching Theo, he is constantly telling me "You are (probably) using XYZ wrong..." 🐞
And like 50% of the time he's right
Some influncer came with "some experience" and just "pretends" that anything that worked in last 20 years is not working anymore because of some personal opinion. For example unit testing. Just please stop it.
Saw those videos and dude just cant answer basic questions why it is not a good idea, just goes around talking about other things and trying to sound like he did answered. Too much bullshiting.
@@Saru-Dono That's what happens when you have a strong opinion on every topic in an industry
@@snakefinn
Yup, but that's why I like Theo. I may not agree with him 100%, but I respect his opinion.
Sometimes he's even right..
The biggest confusion that I’ve seen around this topic is when you include VSCode into the mix.
Is not always clear who’s formatting my code. The vscode extension formatting on save or my precommit hook.
I hope you know my stance on precommit hooks by now
i feel like it's obvious if you're just using prettier installed via npm, or am I missing something
Technically pre-commit hook and extension should derive the state from the same config, so it shouldn't matter in the end. And Prettier doesn't use folder config inheritance nonsense ESLint does, so it's easier to set up and test.
@@ra2enjoyer708 genuinely curious, why even use the extension then when u can have prettier set up as a pre-commit hook which ensures everyone developing the project will have the same formatting?
@@rudyorre because some of us use a shortcut to format the code as we edit it, even without saving.
According to this guy I'm probably living my life wrong
Theo I've only recently found your channel but man am I enamoured (by your content)! You make the best devs videos that aren't just "tutorial/intro to technology" where you gloss over "advanced" topics and only cover superficial and basic level concepts. You truly make videos that devs want to watch, covering a broad range of topics, making informed arguments, and overall just being a top tier dev (uploadthing). Looking forward to the rest of your great work.
These days we expect the tools to be intuitive.
They should just remove the styling functionality in eslint.
The reality is that it isn’t that most developers think they’re better than open source maintainers… It’s that they never think about the maintainers’ existence at all.
Opensource has always had an aspect of putting what you want to have out there, out in the world.
But you're doing it without an expectation that the users act like customers or fans.
Agree, until they are not making a decision to deprecate Eslint-plugin it will be used period.
yes, stylelint already did this and encourage people to use formatters for that
Agreed
We don't know the name of the person that makes our hammer.
I'm sure there's a further analogy with Dunbars number in there was well.
Great video, only thing I don't agree with is not having a prettier config... If you share a repo with even a small team the likelihood that someone has changed their default prettier config is pretty high. I do believe the defaults are fine but setting them in a config so it overrides each team member personal config is the play for me
@@im_arsnl awful take lmao. If that was true there would be 0 reason for the prettier config to even exist... In my experience prettier is there to help straight out of the box with the defaults, but in react with ts I like increasing the printWidth just so I don't have a generic component function spread into 3 lines. It's just straight up personal preference because it compiles to the same code at the end of the day.
I think a good reason for having a prettier config is that it pins down all the defaults or whatever configs you like. That way if the prettier team changes their mind on what a given config value’s default should be, you can still stay witht the same formatting as you had before without creating a PR where 7000 files have changed.
I agree both a linter and formatter have their own use cases. However with prettier I often find it to make the code unreadable when the printwidth is exceeded. I have now used eslint only for a few projects and the only thing I encounter is having to decide when to break a line of code into multiple lines. Adding full Prettier for that for me feels overkill
This is pretty late, but I'm glad to see other people who also think this! Prettier absolutely kills readability. I trust myself and my team to know when to add line breaks for readability, an algorithm will always do worse. I even tried BiomeJS, the new formatter on the block, but it has the same problem. I'm sticking with ESLint and ESLint stylistic for the future UNTIL someone makes a formatter that does NOT add line breaks (ESLint Stylistic basically is that already though)
I like using prettier + ESlint with most harsh rules and auto fix on save
+ auto reloading code
While it would be a breaking change, I feel like ESLint would be doing themselves a big favour if they just removed the ability to have stylistic rules in ESLint altogether. They could have a non-breaking change that just adds a warning message to the output saying, please don't use eslint-plugin-prettier and link to that page you showed, or better yet this video.
yeah. same thought. why is it possible to add simple stylistic rules but also warn everybody "hey please just lint. dont style with eslint". so yeah why is it even possible?! :D
The reason I do Prettier via ESLint is because that's the way I've managed to make things work in a consistent and predictable manner. I hit save in VS Code, and it does both Prettier formatting, and ESLint auto-fixes. If I need to do it from the command-line, it's just a single command I need to run. To check things on the CI server, again, just a single command needs to run. It's maybe a little bit slower, but it works, and I don't have to think about it anymore.
Can you make a quick video on how you would set up Prettier and ESLint in a simple project, in a way that it works seamlessly via VS Code and is easy to integrate in a CI build? I would very much like to learn how to make our setup more performant if that's possible, which it seems like it is.
Personally I use XO for that reason, but even if you don't like it, you can just make a simple npm script for that
@@rea9lizer XO?
npm format && npm lint ?
@@syedahkam7164 Sure, but it's the VS Code side of it in unsure about.
@Svish85 google 'xojs',
it's basically an ESLint + Prettier (optional) wrapper with sensible default and offers an all-in-one command and a VSC ext for Prettier-then-ESLint
In the javascript ecosystem, everyone is using everything wrong. if so many people are using a tool wrong maybe that's a tool problem
the only thing I format with ESLint are my imports, because prettier doesn't care at all about some details I prefer and the plugin by trivago does weird stuff with the AST of prettier, so I'd rather use the ESLint plugin that is guaranteed to work better and basically does the same thing.
1:18 - eslint-config-prettier IS NOT AN ESLINT PLUGIN! It is a config. People are messing up those two things as well a lot
So I entered the video, then liked and subscribed, all because of your mustache.
Later, after watching the video. I realize it's quite good.
One thing that's annoying with Prettier is that ‘trailingComma’ is not set to ‘all’ by default. Trailing commas are really really good for versioning systems like Git, so you always gotta have a prettierrc to enable it. I also like using JSDoc Prettier plugin (it's frankly is a must if you are working with types via JSDoc), wish it would just be included by default. But then, they also completely ignored the request to use tabs by default, which is accessibility concern...
I’m pretty sure they’re moving to tabs soon?
trailingComma will be set to all by default in the next major version of Prettier (v3)
Not sure why UA-cam decided to remove my comment. But to Theo: no, they were going to consider making tabs a default in version 3, but it has been since moved to version 4, so I doubt it happens any time soon.
Tabs vs spaces... Noooo! Not again!
It makes sense that the default has been backwards compatible with es5, but now it's time to move on and change the defaults
This and Josh's talk are honestly great value. Linting and prettier have always been boring tooling I've refused to invest time into learning or caring about. Being able to grok how these 2 tools interop and when was a huge help for me. Keep on keeping on with the great content!
I use eslint-plugin-prettier in my codebases, and it has always worked nicely for me. It's convenient being able to do an eslint autofix and have all the fixable lint issues and formatting errors taken care of with one command. I also like the fact that my formatting issues show up in my code through the eslint extension. Though, it's good to know that if my formatting ever becomes slow then this might be why.
Hey Theo! Thanks for the video. How you you recommend configuring vscode settings to ensure that prettier runs first on save, then eslint afterwards?
nobody knows
I was always expecting that Prettier just uses Eslint in the background, and in that case, it would be better to add prettier to Eslint.
But now i am confusing, and will dive into the prettier code to check how it really works.
Personally i just had really bad experiences with Prettier (Vue Project. That was about >1 year ago. I've spent multiple hours trying to configure prettier for vue templates but it was just annoying and painful. i could give it another try tho)
Josh's talk is a must-watch for 99% of people working in typescript projects
doubt. its completely useless
yep
@@george_davituri nope.
@@ts8960 ok
@@george_davituri cringe
They should make the docs better, i want to see in 30 seconds what to install and what not to install. They even put link tags around things they recommended not to install thats confusing lol. We have colors for a reason. The prettier team and eslint team really should work together to make it more clear if so many devs don’t understand what to do. And not every dev is native English which makes it even harder.
I got a PR rejected to a eslint plugin repo because I failed to understand this exact point. I pushed to use prettier in our team, and my life has been better since
what do you think about import sorting with eslint?
I'm def not pretending to know better than the lib maintainers, it's just confusing to me that eslint supports formatting rules, can apply the formatting automatically, but then they are like "hey don't you dare using eslint for formatting!!1". Why do they build it in in the first place then? Well okay I believe you and will install prettier now ...
Good points on most except for the point about config. This might work on personal projects, but if you are working with multiple developers on a production application you want to have a config file with the define set of rules for that project and also prettier actually installed on the project so that everyone is using the same version of prettier on the project. Nine times out of ten it wont be a problem, but it could save a lot of headache if someone has a weird configured IDE.
...if you install Prettier as a dep, and use the default config, this is the case? I think you misunderstood the point
My thoughts are if the linters don’t want you to style your code with them then they should just remove the stylist rules module from the linter. If you cut the head off the snake so speak, it can’t bite you. If you remove the ability to restyle, it can’t interfere with formatters.
Linters operate on semantics, formatters on syntax.
Can you share a link for that "deprint" you mentioned?
thanks for the tips. i'm finally setup with eslint and prettier CORRECTLY!
There's nothing worse than having a linter tell you that your formatting is wrong. I don't want to know... I just want you to fix it. Formatting lint errors are PURE noise.
Same thing with the Tailwind ESLint plugin, which has formatting enabled by default for some reason. The worst part is that the third party ESLint plugin conflicts with the official Tailwind prettier plugin. Ugh!
I’ll install any extension as long as it’s written in rust
I'm guilty of using ESLint as a formatter and a linter 😁
I'm using Rome for both tasks in smaller projects and it is really fast. It's not that stable, though.
I use ESLint to enforce prettier rules because I dont wanna manually fix linting issues which are very mechanically auto-fixable, while also formatting my code by Prettier standards. I'll take it being slower because it won't be as slow as me going in and fixing stuff manually. For example, I use eslint-plugin-tailwindcss instead of the prettier plugin for tailwindcss (some stupid thing caused my code to be "formatted" very slowly, around 10 seconds for each formatting. I was told it was this plugin. I switched it, and the slowdown went away). Now the plugin tells me the tailwind class order. I don't wanna fix it if the computer can do it hehe. Prettier can't enforce auto fixable linting errors but ESLint can enforce formatting standards, however slow-er. My projects are not nearly large enough to be affected significantly by the slowdown so it works in my case (if that makes a difference).
...just have prettier run format on save then eslint run fixes after? Like everyone is recommending?
You can assign a shortcut, format it on save or run with lint-staged if your IDE don't support it
I will never understand the appeal of format on save. It is one of the most annoying things
Interesting, I usually only use the default ESLint and prettier settings in my VSCode because I just want my code to look consistent and not have to think about some crazy manual configurations....
Our team configures every project with ESLint autofix and Prettier on save. There is no performance issue, and I don't understand any argument why you would want to run the linter separately. I appreciate that the developers of these tools might not intend it to work like this, but when configuring our editors (usually VSCode, sometimes a vim, emacs, etc) having a single config that does both greatly improves consistency.
Cool, gonna take a look at dprint.
I can never get these two to work together properly. When both are active in a project, I always got competition between the two where I'd save, and one would undo formatting that the other did. So I just get rid of prettier and format with eslint. It may be slow, but it works and it's fast enough for me.
it can't be the case when you use eslint-config-prettier properly tho??
@@rea9lizer I've never found the solution that works properly, and it's not for want of trying.
there is a package called "eslint-config-wesbos" and it combines the two, I didn't know about these 2 tools until wes bos and I always used his package to get them both to behave, but after this video I am weighing my options...I like that I can list and beautify my code at the same time
Nice talk, but without a good example of configuration, it's just a talk. Including a detailed pipeline for build and deployment would make it more effective.
The pnpm and tailwind plugin!!! I just faced that recently.. Any pointers where to find more about it?
Agreed. But I think it's better to eslint first and the prettier it, in case eslint autofix will screw the formatting of the file.
Prettier wants && and || at the end and eslint wants them at the beginning
I'll run eslint --fix on save until I die. Don't @ me.
I appreciate the point but have to work on code bases where all the eslint rules are actually formatting rules so you’re kind of stuck in between a rock and a hard place.
Maybe I’ll play this to make my point at the next development sync 😅
What am I doing wrong when my tailwind css prettier auto class sorting works sometimes and sometimes it doesn’t work, this mainly happens when I’m using cva and tv functions. Do others experience on/off sorting functionality?
You looks like a guy from 1800-1900 century. I loved it.
so how about eslint just deprecate the stylistic component
Last linter I've used was TSLint, the only ready to use linter. ESlint it's just bunch of rules that want to make Typescript less Typescript, and it changes every day!!, one day I woke up, updated some dependencies and half of the project was red, how can you say they know better when they can't even agree about which hand are they gonna use to wipe their behinds with the next day. It's a nightmare every time I try it, I always disabled it. Bring back TSlint!!!
Thanks for making me/us aware of dprint, need to look into it.
By the way, there is also this tool called Rome, which is basically a linter and formatter combined into one. Not sure if I am ready to replace ESLint with it yet, cause I have a bucketload of rules that are probably missing since it's still in development, but maybe one day it can and you won't have to make videos like these anymore :)
Rome's dead as fuck lol
Attempt #3 at commenting, I think youtube auto-removes my comments when I reply to you because you have an URL in your username :D
But I wanted to ask what makes you say that? I checked their github repository and it seems very much in active development with like 9 new releases in the past month.
@@dechobarca Rome did the equivalent of what Deno did initially in runtime world: Deno ignored the whole eco-system of npm packages by not supporting them; Rome does not have a way to use exciting or custom ESLint rules and only add support for rules they think needed.
There're other issues with it, but this is the most prominent one in my book.
@@moshyfawn oh okay, thanks a lot for the explanation. That's very unfortunate, migration would be an absolute nightmare now that I think about it, especially for people that maintain a big list of carefully curated rules. Maybe someone makes a tool for migrations, but if they are stubborn in supporting what ESLint supports then I don't see this going anywhere sadly :|
@@dechobarca oh man that checks out actually, good catch
Re: Rome being dead, they significantly downsized the team mid rewrite and have shifted focus significantly. I could be flipped but like they went from the HOTTEST thing to one blog post a year 🤷♂️
THANK you, I'm exactly this opinion
prettier for formatting
eslint for linting
I use only ESLint for my project, the only problem I have is a bug on VSCode configuration, depending on the config, sometimes when I press CTRL + S it applies the lining and removes again if I press the shortcut again, and it keep applying and removing in a loop, it's a bit weird,, I think it's related to the config "editor.formatOnSave"
wouldn't it makes sense to have 1 tool you can either run to format or to lint?
If you could run eslint either with only fixing formatting or with doing linting i can imagen it can be just as fast on the formatting part?
Great video and thanks for the explanation, Theo! 🤙
So essentially I shouldn't use ESLint to check and force code style?
If eslint not formatter, why option in vscode to use as formatter ? 🤷🏾♂️
Every installed extension appears to be an option as a formatter, but it's incorrect to make eslint work. Instead, you configure actions on save.
@@StrikerFeed so is it good practice to run eslint fixAll on file save?
@@shakapaker sure
Nah, this is an old video, but I absolutely hate prettier and formatters in general. For some reason, there is no way to disable the line width option in any formatter, and it forces your code have line breaks in places you don't want them to. A lot of times, it makes things look worse. As a dev, I trust myself and my team to know when to add a new line and when to keep things on the same line for readability. Following an algorithm will not give you the best readability, and I always get worse looking code no matter how much I try to customize the line width option. Too little or too high gives problems in different places. I still use ESLint for formatting because the newer versions work instantly and actually just enforce style rules without ADDING RANDOM LINE BREAKS where I don't want them lol.
Also, the new ESLint separates style rules into a separate package called ESLint stylistic. It's nice.
What was the rust formatter he mentioned? I cant find it
4:23 People will not listen .. because they think better.
This is often a problem of people are being told but not shown replicable proof or reminded of the steps to reproduce the proof.
Then there's also overcome peoples bias from muscle memory or willingness to change config files.
Configs they may already have heavily invested their opinion into , but never tested and proof would wipe that investment.
Sigh.
Plenty of (great!) examples of using eslint wrong, but I must have missed how people are using prettier wrong.
Only a few more videos and theo will have his hood on and headphones on top and cursing JavaScript. The transformation to TheoPrime will be complete!
the pipeline theo > prime is real
If ESLint is not meant to be a formatter, then why does it have formatting rules? Also, Prettier is not flexible. If you don't like else if statements on the same line as a closing curly brace, you're out of luck. I'm sorry, but there's no such thing as a one size fits all formatter. If your formatting tool can't be configured to fit different styles, and you don't like its default style, then it is inferior. For me and my team Prettier is inferior to ESLint for formatting
So have you come around on this one?
Nmms wey te pasas
well opinionated means you use the defined style not customize it to your style
Aah come on , the docs says it's a formatter not a linter, that why people uses eslint with prettier
Personally, I am using both ESLint and Prettier as formatting tools. I think that's not too wrong with that. I am using eslint-plugin-perfectionist, it can cover what Prettier can't do
Get out my head. About a couple hours ago. I was looking to dump prettier because lack of config.
great info, thanks. mind making a video how you setup both working together in a project?
I grew to dislike prettier with passion. Just because some people can't grow up and organize themselves but spend ungodly amount of time picking "the right style" shouldn't hinder my ability to make my own decissions. The "opinionated" part is basically treating us like kids instead of adults and making deccissions for us. Prettier tries to solve several problems at once - format your code AND keep the codebase consistent, without wondering if it should. IMO for superior approach would be a future-reach, customizable, on-demand formatter on the IDE side, so that everyone can work in their preferred style, but opinionated and uniform formatter when pushing to remote to maintain diffs minimal and uniform. No more "bickering" about the code style - you get what you want in your IDE's but the repo is consistent at the same time. Ultimately the style doesn't matter for the semantics... The number of times Prettier made code easier to read was roughly equal to when it made it harder and annoying.
I use prettier to format and just disable linter bc I don’t know or care how to set it up with webstorm.
I don't really mind if it's taking 2 seconds longer than it should be but more than 2 secs are definitely bad. I wish we got a video comparing prettier eslint and the bare prettier one.
What do you need to manually put by using pnpm?
Can you right a full example?
Me configuring typescript, vue, vscode extensions, pinia, router, vite, (previously babel, webpack), tsx, dotenv, tailwind, playwright, vitest, eslint, prettier... It's good to hear the complexity of the last two things are necessary.
Joke. I used bun for several months.
What are your thoughts on prettier plugin for sorted imports?
yoo patreon email gang
🙏
It’s like you read my mind I was about to look into this further and then patron sent me the email
Freddy is that you
It would be great to have a more streamlined TS/JS ecosystem that eliminates the need for tools like prettier, linter, and ts configs. Having to learn and configure these tools can feel like a waste of time. 😿
Hi Theo, ESLint 9.0.0 is out (breaking changes). If you have time/will, please make a video on ESLint and Prettier in a node.js typescript project (e.g. Nest.js).
It would be really appreciated. Thanks in advance.
Cómo sería una configuración de VScode ideal? Cómo trabajar con el formateo si usar o no formatOnSave o eslint on save 😢
here I am using BOTH prettier and eslint for formatting O_o
Theo be cool, there are lots of things not as it should be.
Super helpful, thanks!
im dying for next stream. need it asap Theo!
Why on earth is a linter tool doing formatting in the first place lol.
Incredibly, this is the first thing I was doing right! Hooray, I'm safe 🎉😂
Excelent explanation,
Thank you
The problem is so many framework CLI's set it up wrong in the first place: they enable the eslint prettier-plugin.
The biggest problem with this plugin is now you have red squiggles for any formatting errors. This accomplishes the opposite of what prettier sets out to do: allowing you to completely ignore formatting.
or yellow squiggles, easily distinguishable from linter errors? An no, if prettier just allowed a team of devs to "just ignore formatting" it would be terrible. It's real use is to keep the team working to the same standards, and that can be better achieved (and taught) with code hinting.
Yeah.. nope.. In the end these are tools and if a tool doesn’t do what I want, it is slowing me down.
I would use Prettier if it wasn’t so (over) opinionated. I want to decide when I keep code on one line or move it to the next. Not based on some arbitrary integer value. This to me is really broken in Prettier and you’ll have a hard time convincing me it isn’t 🎉
I'm not a fan of prettier. I prefer to just let people on my team code how they want and avoid the annoying diffs of space adjustments and fille file reformats. Would rather just see the diff that reveals the work actually done, then prior to merge, run the linter and move on with my life.
Wait until Antfu watches this video
Thanks for this informative video.
So we shouldn't run eslint on code save?
hey?
I was talking about this sh*t with some friends a few minutes ago. Thanks
ESLint v8.53.0: Deprecation of formatting rules :)
"This is meant to do this, that is meant to do that" --- it's not an argument, it's a definition (arguably a wrong one, as formatting is part of code quality)
"So many people think they're smarter than OSS people" --- it's not an argument, it's a statement (one which doesn't make sense).
Prettier is intentionally opinionated, so what happens if I want to adjust it with the help of eslint? prettier-eslint is a good answer to me, for which the Notes on the prettier webpage mentioning the downsides - don't make sense as well.
I'm still waiting for the arguments.
It has to do multiple passes, it’s significantly slower, and it fundamentally misunderstands the role of a linter.
You can be stubborn all you want to be. We’re gonna focus on engineering here :)
@@t3dotgg You didn't answer my use case, which is pretty valid. I've been working with a code base which was dominated by long, nested if-else blocks. (Oh, it is OSS, so I'm in the club now?) For those, "stroustrup" if-style made the code much, much readable. Prettier doesn't have an option for that, eslint does.
"multiple passes" - who cares, it's a technical detail. You're putting milliseconds above code readability?
"stubborn", "misunderstands" etc. - blah blah, labels...
@@notramiras if your codebase takes milliseconds to lint, your opinion is irrelevant here :)
@@t3dotgg I took over the code base of 'smashtest' as maintainer and turned it into typescript. It's OOP and stroustrup style. Prettier made it worse not allowing stroustrup.
I don't know what you mean by "my" codebase, and I don't get how nitpicking on milliseconds adds to the conversation, but I didn't feel like lint speed was a problem in my workflow.
Unless you have monster-size source files, it shouldn't be a problem, right?
Is this video speed up or are you really talking that fast? 😅
Nice i wasn't using it wrong.
While the performance and complexity you mention is certainly there, I never ran into major issues with that in eslint. I'd rather use a single tool with the IDEs built-in formatter rules that can be synchronized fairly easily than run yet another tool that lacks on options. The biggest pain point for me in Prettier is how they intentionally limit your ruleset based on their opinion instead of being a tool that can facilitate any opinions. This kind of elimination of tools saves a lot of time with the automation pipelines even if in theory slower, but in reality there is many other steps involved like cloning the repo and spawning up a new container that takes away the actual speed advantage.
been doing this for years
Subscribing for the hair.