Skip to content

Use Prettier as a codeformatter for all* files#300

Open
DrRataplan wants to merge 2 commits into
mainfrom
prettier
Open

Use Prettier as a codeformatter for all* files#300
DrRataplan wants to merge 2 commits into
mainfrom
prettier

Conversation

@DrRataplan

@DrRataplan DrRataplan commented Mar 18, 2026

Copy link
Copy Markdown
Contributor

What

This enables prettier for all JS, CSS, XQuery, Markdown and JSON files.

All editors have some kind of prettier plugin, often even enabled by default. They usually format on save. Otherwise, npm run format just before committing.

Why

At least for me, autoformatting makes my life easier. I do not have to guess codestyle in this file and adhere to it. This is especially nice when working in JS, Cypress tests, XQuery modules and CSS at the same time.

TODO:

  • Prettier mangles the json frontmatter in HTML files. So *.html is excluded for now
  • Prettier fails to parse .tpl. files, because they are not JavaScript or XQuery, but XQuery embedded in jinks-templating files.
    For these we need a new prettier plugin that actually works with jinks-templating files. I'll see what I can come up with.
  • Add the prettier files to the base10 profile to ease up development in generated apps

Discussion

Adding a lot of reviewers because this is kind-of the time to choose options. The following config options are available:

  • tabs vs spaces
    • I am going with spaces here, since that seems to be the most-used in the codebase right now
  • quotes (") vs apostrophies (')
    • I am going with quotes (") here because that seems to be the most used throughout the codebase
  • tab width (how many spaces to use)
    • I am going with 4 here because that seems to be the most used throughout the codebase
  • print width (max line length)
    • I am going with 100 here because that seems to be the most used throughout the codebase
  • semicolon usage
    • I am going with wanting semicolons because again, most used in the codebase as far as I could see.

If anyone has feelings with any of these rules let's talk. Let's discuss this once and enforce it for the future.

I do not recommend you to go through all the files. Just pick a few. This PR just changed the whole codebase. I will make git ignore the big commit for blaming, but only after merging

@line-o line-o left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I support this change

@DrRataplan

Copy link
Copy Markdown
Contributor Author

Since this touches all files there are many conflicts.

The first commit needs to be rebased on main, followed by a npm run format

Not for templates, and not for HTML files because they either do not parse, or give errors.
@JoernT

JoernT commented Apr 21, 2026

Copy link
Copy Markdown
Contributor

I'm missing the instructions how to use in practice. Is the intent that a developer calls (exactly what?) - format or prettier - once in a while ?

But ideally we make it a pre-commit hook that would be called without explicit action by developers - It's just too easy to forget and then you run into the same issue you wanted to avoid.

@JoernT JoernT left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me and certainly help avoid senseless diffs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants