Prettier for formatting supported languages in Jenkins core

[Tim Jacomb]

Hi all

Looking for any feedback on the proposal of using prettier for formatting Jenkins core with the supported languages:

• JavaScript
• CSS
• HTML
• Markdown
• Yaml

See:

https://github.com/jenkinsci/jenkins/pull/6863

Thanks

Tim

[Basil Crow]

First of all, huge thank you to Tim for working on this effort!

+1 from me. I think a consistent and automatically applied set of
formatting rules will make it easier to read and edit these files in
the future.

The most significant objections I have heard so far were that Prettier
poorly formats "if" statements without braces and that applying any
kind of formatting change will make security backports more difficult.
The first of these is being addressed systematically in
https://github.com/jenkinsci/jenkins/pull/6974 by preformatting the
codebase to add curly braces everywhere, and I understand that Tim
plans to address the second objection by backporting the formatting
change to all active branches. I can also volunteer to help address
merge conflicts that arise from the integration of this change, if
that would be helpful.

Two other objections were raised: line length and the removal of
unnecessary parentheses around arithmetic expressions. These are
subjective preferences, and one of the reasons to adopt autoformatting
is to eliminate debate around such subjective preferences in order to
focus collaboration on content (logic) rather than presentation
(formatting). In other words, I acknowledge these objections, but in
my opinion the benefit (being able to effortlessly read and write code
without worrying about formatting) is worth the cost (giving up
control over some subjective preferences for the sake of cohesion).

[Gavin Mogan]

I've always found prettier very opinionated and frustrating to use.

Personally I prefer eslint --fix, which lets you have very fine
control on a lot of things.

But no matter what, I'm 100% in favor of automated tools managing code style.

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjp-b3bg%2BtNJhJuGFnUBEQCTrEobciJzyjjDoQ_5G5T0%2Bw%40mail.gmail.com.

[wfoll...@cloudbees.com]

Thank you very much Tim to start this thread.

> [...] the removal of unnecessary parentheses around arithmetic expressions. These are subjective preferences [...]

I think it's the key point about the complaints again Prettier, it's a very opinionated, meaning that it's not about our subjectivity, but reusing the one from its author. There is no truth about what must be done or not around this kind of style, hence the desire to have this discussion, to find a consensus about the "community subjectivity" instead of relying on someone else opinion. The arithmetic expressions are an interesting example, I am a bit fan of added parenthesis to improve readability, even, when the formula is complicated, to add extra spaces or even lines (like for regex).

Perhaps the "solution" is to simply tell people to use some comment annotations (e.g. https://prettier.io/docs/en/ignore.html) to disable Prettier for formulas and other such expression, why not.

[Basil Crow]

On Tue, Aug 9, 2022 at 2:46 AM 'wfoll...@cloudbees.com' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>
> I think it's the key point about the complaints again Prettier, it's a very
> opinionated, meaning that it's not about our subjectivity, but reusing the
> one from its author. There is no truth about what must be done or not around
> this kind of style, hence the desire to have this discussion, to find a
> consensus about the "community subjectivity" instead of relying on someone

> else['s] opinion.

Please read my previous post about this topic if you have not already. Ceding control of some subjective preferences to an opinionated tool with few (if any) configuration options can be uncomfortable at first, but in my experience the benefits outweigh the disadvantages in the long term. These benefits include never having to deal with a PR that includes a mix of formatting and logic changes (faster code reviews), being able to write code more quickly without having to make formatting decisions, and being able to read code more easily when it is all written in a consistent style.

I have implemented automatic formatting in large organizations many times in my career, and in all cases people complained a little at first but then grew to like it. I myself disliked some of the opinions of the authors of the tools I was putting in place, but putting my own advice into practice I decided to set aside my own opinions for the sake of group cohesion and the benefits described above.

[Gavin Mogan]

I know i said I had issues with prettier being opinionated, but my
issue wasn't the opinions it had, just that it wasn't very flexible.
My personal projects I usually import one of the opinionated rulesets
to eslint and have it done, but eslint is infinitely configurable,
while my experience, at least when I last used it, prettier was
frustrating to manage. I'm all about tooling being opinionated.

So absolutely not against prettier, just more of a "have you look at
eslint instead? it also has the ability to keep an eye on other things
like using undefined variables"

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjpz6ieWaXWQx8coavENczXDTDTkr3ei7dq86Q4XdXZrgw%40mail.gmail.com.

[Tim Jacomb]

We have eslint as well to do things like what you said

My preference is for opinionated formatters so we don’t have to worry about debating options and it does a really good job by just automatically formatting it, you don’t get red lines in your IDE as you type distracting you like you do with eslint if you’re using it for formatting, as the expectation is you run the format before committing

Places where the formatted is doing some we really don’t want can have an ignore comment added to it

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuvtX1pat5VdtsoN7QrLa%2BTfbDr%2B8u0DFxpGwP3%2BCQXHqg%40mail.gmail.com.