Enable prettier

[timja]

Ref #5916 (comment)

Automatically lint (and fix) files supported by prettier

• css
• JavaScript
• html
• markdown
• yaml

Prettier is an opinionated formatter that can be used to reformat code to match a consistent style.

I've integrated eslint with it so that they won't conflict
Prettier automatically reads the .editorconfig file to read some basic options as well.

Specific sections where the layout produced by prettier is harder to read than what the developer wants can be disabled with https://prettier.io/docs/en/ignore.html

If this is accepted I plan to add a .git-blame-ignore-revs file so this change is ignored in blames.

Interesting files that changed are:

• war/package.json
• war/pom.xml
• war/.prettierignore
• war/.eslintrc.js
• CONTRIBUTING.md

[daniel-beck]

Please hold until the number of open PRs is at a minimum.

[NotMyFault]

How well does that rule out with the recently added integrations like ESLint on ci.j? E.g. in case of a violation found

Do we really need (and want) prettier for markdown and yaml? It looks like it's prefectly fine for frontend files only, though what about handlebars?

[timja]

How well does that rule out with the recently added integrations like ESLint on ci.j? E.g. in case of a violation found

Basically: https://prettier.io/docs/en/integrating-with-linters.html

A bit further to this, prettier's opinion is you don't need to know what is wrong, just run the format command and it will fix it for you, so there's no CI view or local tool you need to run it and diff it to see what the changes are.

Do we really need (and want) prettier for markdown and yaml? It looks like it's prefectly fine for frontend files only, though what about handlebars?

🤷 can back it out if we don't want it.

though what about handlebars?

It doesn't support handlebars in the core (https://github.com/timja/jenkins/blob/22022993b29b5498e7ec272a45cd43359951da5c/war/.prettierignore#L24)

I did find a plugin but it seems basically unused so not sure about it (https://github.com/ratierd/prettier-plugin-hbs)

no change in this PR requested, I'll mark as on hold for a bit unless others disagree

[github-actions]

Please take a moment and address the merge conflicts of your pull request. Thanks!

[jglick]

This is pretty unfortunate.

[timja]

cc @jenkinsci/sig-ux

[basil]

The CI build seems to fail on Windows.

[NotMyFault]

The CI build seems to fail on Windows.

Windows attempts to enforce CRLF with prettier, but the files use LF, as configured.

[timja]

The CI build seems to fail on Windows.

Windows attempts to enforce CRLF with prettier, but the files use LF, as configured.

Doesn't seem to do that in general.
I started a windows 11 VM.

Installed java,maven and git
Did no configuration at all.

Lint passed just fine.

Ran out of time but I'll start a VM based off of the CI image later on.

Would ❤️ it if someone on Windows already could take a look.

I've had a look through the prettier issues, as far as I can tell it tries to autodetect line endings and leaves them alone, (it also supports configuring an explicit one).

We have a .gitattributes set for auto eol conversion which I think leaves them alone in the checked out code but will convert on check in.

[NotMyFault]

The CI build seems to fail on Windows.

Windows attempts to enforce CRLF with prettier, but the files use LF, as configured.

Doesn't seem to do that in general. I started a windows 11 VM.

That was the case when I ran lint:fix. Figures, my surface had autocrlf set to true in its .gitconfig. Unsetting this behavior makes prettier not fail the build.
Running lint:fix again leaves no changed files anymore.

[timja]

That was the case when I ran lint:fix. Figures, my surface had autocrlf set to true in its .gitconfig. Unsetting this behavior makes prettier not fail the build.

It seems like that is somewhat recommended for windows:
https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings

[timja]

(you can ignore merge conflicts they are easily addressed but I don't want to constantly be doing it)

[timja]

/label ready-for-merge

---

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!

[timja]

Backported to:

• stable-2.361
• stable-2.346
• stable-2.332
• stable-2.319

[basil]

Thanks, Tim! I just went through and resolved a bunch of conflicts in open PRs. Could use your help in resolving the logical conflicts in #6511 and #6408.

[daniel-beck]

Caused JENKINS-69498

[jglick]

What might have been obvious to the author but took me a long time to figure out, and seems to be missing from any guides: how you actually fix warnings. AFAICT:

mvn -pl war frontend:yarn -Dfrontend.yarn.arguments=lint:fix

[timja]

Ah it was in a guide here but got dropped through all the rebasing accidentally I’ve had a PR open for a couple of weeks to automatically fix these on commit:
#7075

[basil]

Those of us who hate Git hooks will never use #7075, so I think it is worth improving the error message and/or documentation to instruct the user about how to fix lint errors using Maven.

[basil]

Broke javaposse.jobdsl.plugin.EmbeddedApiDocGeneratorSpec, as discovered in jenkinsci/job-dsl-plugin#1265.

[daniel-beck]

Caused JENKINS-70788.

[basil]

Broke io.jenkins.plugins.casc.ConfigurationAsCodeTest#testHtmlDocStringRetrieval and io.jenkins.plugins.casc.SchemaGenerationSanitisationTest#testRetrieveDocStringFromAttribute, as discovered in jenkinsci/configuration-as-code-plugin#2234.