The container development community has been discussing a new tool called dockerfmt that aims to standardize and improve Dockerfile formatting. This tool, built on top of the internal buildkit parser, seeks to bring the same kind of auto-formatting capabilities to Dockerfiles that developers have come to expect in other programming languages.
Modern Dockerfile Formatting with Limitations
Dockerfmt offers several useful features for developers working with container definitions, including formatting RUN steps with mvdan/sh, support for basic heredocs, and handling of inline comments in run steps. The tool provides command-line options for checking formatting, writing formatted output back to files, controlling indentation, and ensuring files end with trailing newlines. However, community members have pointed out several limitations that might affect its adoption. According to the documentation, the RUN parser doesn't support grouping or semicolons in commands, there's no line wrapping for long JSON commands, and the #escape=X directive isn't supported.
One community member highlighted these limitations, noting:
I am firmly in the camp of RUN set -e ;\ export DEBIAN_FRONTEND=noninteractive ;\ etc etc - so I guess this tool isn't for me
Key Features of dockerfmt
- Format RUN steps with mvdan/sh
- Support for basic heredocs
- Support for inline comments in run steps
- JS bindings available
Limitations
- RUN parser doesn't support grouping or semicolons in commands
- No line wrapping for long JSON commands
- escape=X directive not supported
Command Options
-c, --check: Check if files are formatted-w, --write: Write formatted output back to files-1, --indent uint: Number of spaces for indentation (default 4)-n, --newline: End file with trailing newline
Growing Ecosystem of Container Build Tools
The discussion around dockerfmt has expanded into a broader conversation about the container image building ecosystem. Community members debated the merits of continuing to use Dockerfiles versus alternatives like Podman, Buildah, buildpacks, Nix, kaniko, ko, bazel, and apko. Each alternative offers different tradeoffs compared to traditional Dockerfiles. For instance, Buildah was highlighted as providing the same familiar tools (RUN, ADD, etc.) but within a more powerful shell environment, though at the cost of automatic layer caching.
Community Adoption and Integration
The tool has already gained some traction in the developer community. One commenter mentioned integrating dockerfmt into their universal code linter and formatter called Qlty CLI, noting that the plugin took only about ten minutes to add. This quick integration suggests dockerfmt has a straightforward API that makes it accessible for tool builders.
Some users pointed out the irony that the dockerfmt project itself doesn't include a Dockerfile, making it difficult for developers to quickly test the tool in a containerized environment. The project maintainer responded to this feedback, promising to distribute a Docker release of the binary soon.
As automated code generation through LLMs becomes more common, tools like dockerfmt may become increasingly important for maintaining clean, consistent code across projects. The standardization of formatting across all languages and configuration files helps keep diffs clean and makes codebases more maintainable, especially in collaborative environments.
Reference: dockerfmt