Interest checks for integrating dts formatter

[urob]

Opening this issue to see if there is demand for a PR that integrates auto-formatting of Devicetree files (dts, dtsi, overlay, keymap) using dts-linter.

Background

dts-linter is the CLI frontend to dts-lsp. Both projects are quite new and explicitly tailored towards zephyr Devicetree files. By default, the formatting adheres to the Zephyr's Devicetree styleguide. The project maintainer @kylebonnici and I have worked together for the past weeks to fix various bugs in the LSP that prevented it from running on the ZMK codebase (okay, it was mainly Kyle doing the fixing), as well as add a few customization flags to the CLI frontend needed for ZMK.

Suggested plan

• Prepare existing codebase
  • Fix one code instance where the linter errors (and which can't be fixed on the linter-side)
  • Guard manually aligned arrays (bindings, map and a few others) with dts-format off (if reformatting of the existing codebase is desired)
• Apply formatter to existing codebase (???)
• Add dts-linter pre-commit hook and move ownership of the hook to zmkfirmware or kylebonnici if desired.
• Add a GHA check for formatting of Devicetree files for new PRs
• Document formatter usage

If those sound like useful additions, I'd be happy to draft PRs to implement any that make sense.

Open questions

• Formatter setup: dts-linter allows for a few custom settings. Do the following make sense?

  • Indent with spaces using 4 spaces
  • Max linewidth of 120 (except when guarded with dts-format off)
  • Otherwise apply the Zephyr Style

• Formatting fences: If reformatting of the existing codebase is desired, what should be fenced off?

  • Keymap bindings if currently manually aligned (yes?)
  • bindings for 2x2 test keymaps (no?)
  • Matrix transform maps if currently manually aligned (??)
  • Physical layout keys if w, h, x, y, rot, rx, ry is aligned (yes?)
  • Anything else?

• Config file: dts-linter currently doesn't have the option to add a configuration file. This isn't a problem for the pre-commit hook or when configuring the LSP through the editor, but for local development on the CLI it's a nuisance. We can either try to convince @kylebonnici to add a config option or add a small shell-wrapper to the zmk repo that calls dts-linter with the appropriate CLI args.

Diff against current codebase

https://github.com/zmkfirmware/zmk/compare/main...urob:zmk:dts-linter-diff?expand=1

A few observations:

• Manual aligned arrays require dts-format off fences (see above)
• Lack of placement formatting for in-line comments. Mainly a consistency issue?
• Lot's of changes due to applying the Zephyr Style Guide (I find them largely sensible)

Related

• DeviceTree Formatter #583 (more general issue)
• Recomand dts lsp #3362 (complementary PR to set up the LSP in vscode)

[kylebonnici]

I would not mind extending the dts-linter to consume a config file

[petejohanson]

I think this would be a definite improvement, yes! Let me look at the details on this issue this week.

[kylebonnici]

@urob re config file I am trying to understand what you need so that I can action feel free to open an issue on LSP or linter repo and we can take it from there

[urob]

@urob re config file I am trying to understand what you need so that I can action feel free to open an issue on LSP or linter repo and we can take it from there

Perfect timing, I was just typing a response to your first comment :)

Motivation

Right now, I think, there's now way to persist a configuration when formatting via dts-linter. Formatting files using the ZMK style requires:

dts-linter --formatFixAll --insertSpaces --tabSize 4 --wordWrapColumn 120

This is a bit inconvenient, especially when wanting all contributors to apply the same style. Hence, the need for a per-repo config file.

Desired behavior

My preferred behavior would be a single dts-linter.conf (or yaml, json, etc) file at the repo root where one can configure any of the LSP options. E.g.,

wordWrapColumn: 120
insertSpaces: True
tabSize: 4

If such a config file exists, this would overwrite the corresponding default options of both the CLI tool and any other call to the LSP server (e.g., from VSCode and other editors).

Order of precedence

It might be worth getting more feedback on this. My first instinct would be the following order (from highest to lowest)

1. CLI arguments (dts-linter) and LSP configuration inside the editor (dts-lsp calls via the editor)
2. dts-linter.conf at the repo root
3. Defaults (That is, CLI defaults for the dts-linter and the server defaults for other dts-lsp calls)

[kylebonnici]

@urob > dts-linter.conf at the repo root

this is for when the user runs dts-linter CLI as part of some pre commit hook right? .... project in editors will sill need #3362 to use LSP with right settings correct?

[urob]

@urob > dts-linter.conf at the repo root

this is for when the user runs dts-linter CLI as part of some pre commit hook right? .... project in editors will sill need #3362 to use LSP with right settings correct?

My hope was that it applies to both dts-linter when run by the user on the CLI (or the pre-commit hook) and dts-lsp when invoked by the editor directly (unless the settings are overwritten by the LSP config in the editor). This way there would be a single source of truth for the ZMK style.

But if that's not feasible, then yes, having a config file just for dts-linter is the one which we currently don't have a workaround (short of writing a custom wrapper).

Re: #3362, if the config also applies to the server, then one could remove the style settings from the vscode config. But one would still need the PR to configure the various include paths so that linting works beyond flagging formatting errors. EDIT: actually, my preferred behavior would also allow setting those in the global config. So the other PR would be mainly about setting up the LSP for VCCode.

---

EDIT: opened an issue in kylebonnici/dts-linter#16 to keep the discussion here focused on the ZMK side of things.