Using Prettier in Gitea #12349

@6543 commented on GitHub (Jan 19, 2024):

i'm for adding it, it is more strict as eslint

eslint focus on linting while prettier on formating.
so i'm for a tandem

@6543 commented on GitHub (Jan 19, 2024): i'm for adding it, it is more strict as eslint eslint focus on linting while prettier on formating. so i'm for a tandem

GiteaMirror commented

@6543 commented on GitHub (Jan 19, 2024):

let me just make an experimet by adding a pipeline for linting it :)

@6543 commented on GitHub (Jan 19, 2024): let me just make an experimet by adding a pipeline for linting it :)

GiteaMirror commented

@leon-win commented on GitHub (Jan 19, 2024):

We have eslint and I think it provides the same functionality?

ESLint is also good tool 👍
However, with its help you can solve only a part of the problems, mainly related to syntax checking and errors. While Prettier helps to format the display of code in a single style, that is, it complements ESLint.

There is comparison of Linters vs. Prettier

To make it more clear:

CSS

JavaScript

Vue.js

@leon-win commented on GitHub (Jan 19, 2024): > We have eslint and I think it provides the same functionality? ESLint is also good tool :+1: However, with its help you can solve only a part of the problems, mainly related to syntax checking and errors. While Prettier helps to format the display of code in a single style, that is, it complements ESLint. There is [comparison of Linters vs. Prettier](https://prettier.io/docs/en/comparison) To make it more clear: CSS ![image](https://github.com/go-gitea/gitea/assets/1682136/4865d36a-eca8-4613-9ffb-9dbedbe14739) JavaScript ![image](https://github.com/go-gitea/gitea/assets/1682136/1a634910-f2ba-437f-9596-adbe9d8be9a3) Vue.js ![Screenshot from 2024-01-20 02-00-38](https://github.com/go-gitea/gitea/assets/1682136/4b6ae605-8692-44d8-a113-9cbe121d0546)

GiteaMirror commented

2025-11-02 10:06:35 -06:00

@lunny commented on GitHub (Jan 21, 2024):

How about biome?

@lunny commented on GitHub (Jan 21, 2024): How about biome?

GiteaMirror commented

@denyskon commented on GitHub (Jan 21, 2024):

@lunny I suggested it and then deleted the comment immediately - I noticed biome doesn't support CSS currently, and I'm unsure about Vue.

@denyskon commented on GitHub (Jan 21, 2024): @lunny I suggested it and then deleted the comment immediately - I noticed biome doesn't support CSS currently, and I'm unsure about Vue.

GiteaMirror commented

2025-11-02 10:06:35 -06:00

@wxiaoguang commented on GitHub (Jan 21, 2024):

I don't like prettier because it isn't smart enough.

For example, some code could only need one line, but prettier insist to use multiple lines, using prettier aggressively reduces readability IMO.

Indeed there are a lot of options for prettier, maybe some behaviors could be fine-tuned, but I just feel satisfied about current code style, so personally I have no motivation to introduce prettier or re-format all the frontend code (that's just my opinion, no block if major maintainers would like to re-format).

@wxiaoguang commented on GitHub (Jan 21, 2024): I don't like prettier because it isn't smart enough. For example, some code could only need one line, but prettier insist to use multiple lines, using prettier aggressively reduces readability IMO. ---- Indeed there are a lot of options for prettier, maybe some behaviors could be fine-tuned, but I just feel satisfied about current code style, so personally I have no motivation to introduce prettier or re-format all the frontend code (that's just my opinion, no block if major maintainers would like to re-format).

GiteaMirror commented

@denyskon commented on GitHub (Jan 21, 2024):

I also agree that using prettier could break a lot. For example many of our helper classes are written as one-liners by design, and reformatting them to become 3+ lines will decrease readability and make files way longer. I'm satisfied with current formatting, and ESLint does a good job when enforcing important rules

@denyskon commented on GitHub (Jan 21, 2024): I also agree that using prettier could break a lot. For example many of our helper classes are written as one-liners by design, and reformatting them to become 3+ lines will decrease readability and make files way longer. I'm satisfied with current formatting, and ESLint does a good job when enforcing important rules

GiteaMirror commented

@6543 commented on GitHub (Jan 21, 2024):

Well if we add it, i would say we can just tweek prettier to not do what we dislime and config it so it matches mostly what we alread use, so the diff should then be not huGe

@6543 commented on GitHub (Jan 21, 2024): Well if we add it, i would say we can just tweek prettier to not do what we dislime and config it so it matches mostly what we alread use, so the diff should then be not huGe

GiteaMirror commented

@lunny commented on GitHub (Jan 22, 2024):

OK. I think we can close this one currently if there is no further arguments in 1 month.

@lunny commented on GitHub (Jan 22, 2024): OK. I think we can close this one currently if there is no further arguments in 1 month.

GiteaMirror commented

@harryzcy commented on GitHub (Jan 23, 2024):

we can configure prettier to run against changed files, so existing files won't need any edits

@harryzcy commented on GitHub (Jan 23, 2024): we can configure prettier to run against changed files, so existing files won't need any edits

GiteaMirror commented

@leon-win commented on GitHub (Jan 23, 2024):

OK. I think we can close this one currently if there is no further arguments in 1 month.

I will try to answer all questions and give arguments along the way 👌

I don't like prettier because it isn't smart enough.

For example, some code could only need one line, but prettier insist to use multiple lines, using prettier aggressively reduces readability IMO.

"IMO" is the key point in this case) I mean is that all developers may have their own subjective view of the correct (or best) formatting. And against this background, disputes often arise, which can take up time. The purpose of the formatter is to make the code style uniform. It doesn’t matter in what style, but what matters is that it’s consistent.

That is, Prettier is smart enough, but it has a different goal -- to make all the code in the same style. In order not to deal with questions of a subjective nature.

Indeed there are a lot of options for prettier, maybe some behaviors could be fine-tuned, but I just feel satisfied about current code style, so personally I have no motivation to introduce prettier or re-format all the frontend code (that's just my opinion, no block if major maintainers would like to re-format).

Unfortunately (or fortunately 🙂) on the contrary, it has very few settings. And this is not a drawback, but the essence of the approach.

I encourage everyone to read the description of Prettier Option Philosophy to understand the advantages of this approach.

I also agree that using prettier could break a lot. For example many of our helper classes are written as one-liners by design, and reformatting them to become 3+ lines will decrease readability and make files way longer. I'm satisfied with current formatting, and ESLint does a good job when enforcing important rules

"one-liners by design" sounds strange, as if the purpose of the code is not to perform some business function, but simply to look the right way. But that's not true, is it?)

About decreasing readability -- it is also very subjective. Yes, it will take some getting used to the new formatting. But this only needs to be done once. And it takes only several days.

But after this, work productivity increases! 🚀)) Because when opening any file in a project, the brain will not waste time adjusting to custom formatting. Moreover, not only in Gitea but in any project that uses the same formatting! This is why Prettier has almost no settings -- so that in any project, the formatting is the same and it is much easier for the developer to switch.

As for increasing the file size (number of lines), I think this is not a matter of formatting, but of architecture. If the file becomes too large, it needs to be decomposed. Trying to reduce the number of lines by formatting is masking the problem, not the solution.

ESLint is a very good tool, but it performs other tasks, I already wrote about this above. ESLint and Prettier complement each other.

Well if we add it, i would say we can just tweek prettier to not do what we dislime and config it so it matches mostly what we alread use, so the diff should then be not huGe

I think it's better to be ready for a large number of changed files right away)) because, as I noted above, Prettier is opinionated code formatter, that is, it implies an minimal configuration (and this is not a bug, but a feature of the approach). But it is possible to ignore code that does not need to be formatted, so we can apply it gradually, in parts (if for some reason it seems better).

we can configure prettier to run against changed files, so existing files won't need any edits

You can do it like this. But this greatly reduces the benefit of its implementation in my opinion)

Why do one-time big changes cause such fears?

If there are concerns that the code will become inoperative, then this is impossible.

I see only one potential problem: if at the time of merging PR with Prettier there are unmerged changes regarding static files (*.css, *.js, *.json, *.vue), then it will be necessary to merge the main branch to them and perform formatting. But I think it's not that difficult to do. Ready to help resolve conflicts if they arise =)

@leon-win commented on GitHub (Jan 23, 2024): > OK. I think we can close this one currently if there is no further arguments in 1 month. I will try to answer all questions and give arguments along the way :ok_hand: > I don't like prettier because it isn't smart enough. > > For example, some code could only need one line, but prettier insist to use multiple lines, using prettier aggressively reduces readability IMO. "IMO" is the key point in this case) I mean is that all developers may have their own subjective view of the correct (or best) formatting. And against this background, disputes often arise, which can take up time. The purpose of the formatter is to make the code style uniform. It doesn’t matter in **what** style, but what matters is that it’s **consistent**. That is, Prettier is smart enough, but it has a different goal -- to make all the code in the same style. In order not to deal with questions of a subjective nature. > Indeed there are a lot of options for prettier, maybe some behaviors could be fine-tuned, but I just feel satisfied about current code style, so personally I have no motivation to introduce prettier or re-format all the frontend code (that's just my opinion, no block if major maintainers would like to re-format). Unfortunately (or fortunately :slightly_smiling_face:) on the contrary, it has very few settings. And this is not a drawback, but the essence of the approach. I encourage everyone to read the description of [Prettier Option Philosophy](https://prettier.io/docs/en/option-philosophy.html) to understand the advantages of this approach. > I also agree that using prettier could break a lot. For example many of our helper classes are written as one-liners by design, and reformatting them to become 3+ lines will decrease readability and make files way longer. I'm satisfied with current formatting, and ESLint does a good job when enforcing important rules "one-liners by design" sounds strange, as if the purpose of the code is not to perform some business function, but simply to look the right way. But that's not true, is it?) About decreasing readability -- it is also very subjective. Yes, it will take some getting used to the new formatting. But this only needs to be done once. And it takes only several days. But after this, work productivity increases! :rocket:)) Because when opening any file in a project, the brain will not waste time adjusting to custom formatting. Moreover, not only in Gitea but in any [project that uses the same formatting](https://prettier.io/en/users/)! This is why Prettier has almost no settings -- so that in any project, the formatting is the same and it is much easier for the developer to switch. As for increasing the file size (number of lines), I think this is not a matter of formatting, but of architecture. If the file becomes too large, it needs to be decomposed. Trying to reduce the number of lines by formatting is masking the problem, not the solution. ESLint is a very good tool, but it performs other tasks, I already wrote about this above. ESLint and Prettier complement each other. > Well if we add it, i would say we can just tweek prettier to not do what we dislime and config it so it matches mostly what we alread use, so the diff should then be not huGe I think it's better to be ready for a large number of changed files right away)) because, as I noted above, [Prettier is opinionated code formatter](https://prettier.io/docs/en/), that is, it implies an minimal configuration (and this is not a bug, but a feature of the approach). But it is possible to [ignore code that does not need to be formatted](https://prettier.io/docs/en/ignore), so we can apply it gradually, in parts (if for some reason it seems better). > we can configure prettier to run against changed files, so existing files won't need any edits You can do it like this. But this greatly reduces the benefit of its implementation in my opinion) Why do one-time big changes cause such fears? If there are concerns that the code will become inoperative, [then this is impossible](https://prettier.io/docs/en/rationale#what-prettier-is-_not_-concerned-about). I see only one potential problem: if at the time of merging PR with Prettier there are unmerged changes regarding static files (`*.css`, `*.js`, `*.json`, `*.vue`), then it will be necessary to merge the main branch to them and perform formatting. But I think it's not that difficult to do. Ready to help resolve conflicts if they arise =)

GiteaMirror commented

@lafriks commented on GitHub (Jan 24, 2024):

Imho prettier should be integrated as eslint plugin so linting can be done in single step not by running multiple tools

@lafriks commented on GitHub (Jan 24, 2024): Imho prettier should be integrated as eslint plugin so linting can be done in single step not by running multiple tools

GiteaMirror commented

@leon-win commented on GitHub (Jan 25, 2024):

Imho prettier should be integrated as eslint plugin so linting can be done in single step not by running multiple tools

Technically this is possible, but this approach has more disadvantages.

What's wrong with using a special tool for each task?

For JavaScript linting -- JSLint,
For CSS linting -- Stylelint,
To format both (and more) -- Prettier.

This is the ideal way in my opinion.

@leon-win commented on GitHub (Jan 25, 2024): > Imho prettier should be integrated as eslint plugin so linting can be done in single step not by running multiple tools Technically this is possible, [but this approach has more disadvantages](https://prettier.io/docs/en/integrating-with-linters.html#notes). What's wrong with using a special tool for each task? For JavaScript linting -- JSLint, For CSS linting -- Stylelint, To format both (and more) -- Prettier. This is the ideal way in my opinion.

GiteaMirror commented