Feature Description

Hello everyone!

I recently started working with the Gitea (mostly frontend).

And almost immediately I had a question -- why doesn’t it use Prettier? I couldn't find the answer by searching in PRs and Issues))

Are there any fundamental reasons? Or just not have enough time to implement it?

Which place do you think Gitea need that?

We format with make fmt, is there a problem with the command?

@lunny, @yardenshoham, thank you for replies!

Which place do you think Gitea need that?

Prettier will work great for files inside web_src/ (*.css, *.js, *.json, *.vue).

We format with make fmt, is there a problem with the command?

As far as I understand, this command only formats *.tmpl files. But the project does not yet have a tool for automatically formatting static files.

The advantages of using an automatic formatter are described, for example, here, but in a nutshell it's: consistent code style and format, saving time and reducing the chances of human error.

Prettier is one of the best solutions for this, details can be found here.

If no one has any fundamental objections, then I can make a PR with the applying of the Prettier to Gitea. However, we must be prepared for the fact that there will be a lot of changes (the initial formatting will affect almost all CSS, JavaScript and Vue files =)

We have eslint and I think it provides the same functionality? I just tried adding a space to an import and ran make lint and it printed an error

I then ran npx eslint --color --max-warnings=0 --ext js,vue web_src/js build *.config.js tests/e2e --fix and it reverted my change

cc @silverwind

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

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

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

To make it more clear:

CSS

JavaScript

Vue.js

How about biome?

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

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).

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

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

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

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

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 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! 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 =)

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

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.

I'm against prettier, especially for CSS. Often times formatting is used for good reason:

• Visual grouping of simple selectors on one line:

.red { color: red }
.blue { color: blue }

• Grouping of related selectors with no newline between:

.a {
 color: red;
}
.a .b {
  color: blue;
}

.b {
 color: red;
}
.b .b {
  color: blue;
}

Also in JS there are cases of compact single-line formats that prettier renders not too well, like this:

  expect(await pngChunks(await dataUriToBlob(pngNoPhys))).toEqual([
    {name: 'IHDR', data: new Uint8Array([0, 0, 0, 1, 0, 0, 0, 1, 8, 0, 0, 0, 0])},
    {name: 'IDAT', data: new Uint8Array([8, 29, 1, 2, 0, 253, 255, 0, 0, 0, 2, 0, 1])},
    {name: 'IEND', data: new Uint8Array([])},
  ]);

A automatic formatter can never be as good as humans. While I do understand the benefits of uniform formatting, I think we can catch such cases easily during review. Take this example which prettier blows up from 29 to 55 lines, almost doubling the line count for no good reason.

@silverwind, hi! All of the above examples show the subjective tastes of one particular developer. That is, for example, you like compact one-line fragments, someone else may not like them. In order not to waste time discussing the formatting used, drawing up guidelines and potential disputes, such a formatter is needed. Prettier always formats everything in the same style. This is its purpose, not a flaw or defect.

A automatic formatter can never be as good as humans. While I do understand the benefits of uniform formatting, I think we can catch such cases easily during review.

Discussing formatting in a code review is exactly what everyone tries to avoid))) This is a real anti-pattern. This takes time away from understanding the business essence and logic of changes. You can read more on the page Why Prettier?

Take this example which prettier blows up from 29 to 55 lines, almost doubling the line count for no good reason.

As for the example, for my taste it’s better with formatting (because I’m used to working with this formatting, and I perceive it well and quickly).

I would also add blank lines between expect in the source code and disable formatting for "data:image/png;base64" constants (they really look awkward after formatting). So, in my opinion, this is ideal:

What is the reason for the fear of increasing the number of lines? Gitea has files that are thousands of lines long! And of course this is a lot, but I think we all understand that we need to reduce their size not by formatting, but by decomposition? =)

In the JS example, I find our formatting easier to read because name and data are vertically aligned, but prettier broke the alignment with the last element where it thought to fit it on one line. Likely this can be tweaked with max line length option and I would recommend around 110 based on my current screen width of 112, thought others should chime in as well.

If you wanna try adding it, add separate make targets make fmt-js, make fmt-go (current fmt) and make fmt (combines both). Find the set of options that introduce the smallest diff. Only do JS, no CSS. Also need to disable/uninstall formatting-related eslint rules.

TOC decided to not use it ...

... still thanks to all who participated and point out the different view points, use-cases, edge-cases, etc .. :heart:

Yeah I think we are better off without for now.

On Topic: Golang also has a formatter which we use, and it produces such great diffs like this because of its stupid alignment.