prettier-plugin-tailwindcss VS prettier

It's not as if the correct order for the rules is mysterious. It's implemented in the Tailwind compiler. Tools like prettier-plugin-tailwindcss, which automatically sorts the class names in your HTML code to match the order in which Tailwind generates them in your CSS output, use a public API in Tailwind to get this order.

Other than that, you can get Prettier sorting your classes with the Tailwind Prettier plugin. And one more quality-of-life extension that might help your eye sores from a long list of classes is Tailwind Fold.

I everyone. I am using Electron react boilerplate and I have successfully added tailwindcss to the project. However, I am struggling to get the Prettier plugin tailwindcss to work. I’ve tried following the instructions in the readme but no luck. I’ve tried moving my prettier.config.js to the .erc/config dir with no luck either.

Others have already replied, but if you need to structure your TailwindCSS classes, I recommend their official Prettier plugin which integrates well into an ESLint setup.

> Except that I read that it's great for writing, but a nightmare for reading.

This is true at first. I can see it being pretty daunting to come into an existing project and trying to understand the styling of components. Starting from scratch and easing it into an existing project is much easier imo. That's what I did for a personal website. Now that I understand it and have converted the entire website to Tailwind, I don't want to switch to anything else going forward.

Here's a Prettier plugin that sort the classes to keep everything consistent across components: https://github.com/tailwindlabs/prettier-plugin-tailwindcss

Tailwind combined with classnames (https://github.com/JedWatson/classnames) makes it really easy to have conditional styling based on component state.

Despite the existence of Prettier, arguments about code style such as how to sort ES module imports still exist. Manually sorting ES modules wastes time, and usually leads to losing context when you are writing code and then have to navigate to the top of a file to modify your import statements. I love using the @trivago/prettier-plugin-sort-imports plugin which automatically sorts new imports, and works perfectly together with TypeScript's auto-import feature. Similarly, prettier-plugin-tailwindcss automatically sorts Tailwind classes in your code.

Added the tailwind-prettier-plugin as not everyone uses headwind

I used to use Headwind (mentioned in another comment) but the Tailwind CSS team now maintains an official Prettier plugin which I'd recommend using on every project. It sorts the classes the same way they appear in Tailwind's compiled CSS so precedence is easy to see straight from your HTML. I've also found it's much faster than Headwind. They talk about it more in this blog post.

We are using prettier as pre-commit hook so instead of installing prettier-plugin-tailwindcss as npm dependency we will add it as additional_dependency for our prettier hook.

No formatting inconsistencies: The committed code should follow the organization's code formatting standards(prettier or pretty-quick).

Let’s walk through the steps for a one-time setup to configure husky pre-commit and pre-push hooks, ESLint with code styles conventions, prettier code formatter, and lint-staged. Husky automatically runs a script on each commit or push. This is useful for linting files to enforce code styles that keeps the entire code base following conventions.

GitHub | Website

Prettier: An opinionated code formatter that enforces a consistent code style.

What is Prettier 😎?

In this Thread, I won't show you little extensions that you probably already know, like Live Server or Prettier.

1.1k isn't bad for a project with ~33 million weekly downloads[1], imo. Yes, I know that's not necessarily a good metric, but it's ~10 million more than React[2] which also has a similar number of open issues[3].

[1]: https://www.npmjs.com/package/prettier

[2]: https://www.npmjs.com/package/react

[3]: https://github.com/facebook/react

Actually that comment derives onto this other issue, where the merits of the decision are discussed:

https://github.com/prettier/prettier/issues/15956

and to be honest, it didn't look like silly to me :) It was an interesting read for me, who as a maintainer, I tend to give more importance to the official statements such as in this case written recommendations of the source company that defined the new format.

https://github.com/prettier/prettier/issues/15942#issuecomme...

Another example: https://github.com/prettier/prettier/issues/187

That issue has been open for 7 years.