tally: v0.27.0

[tinovyatkin]

Publishing version v0.27.0 of the tally extension.

Tally is a Dockerfile linter and formatter written in Go, promoting modern container syntax and helping avoid common pitfalls.

Changelog

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @github-actions[bot] on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @tinovyatkin on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @tinovyatkin on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @tinovyatkin on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[tinovyatkin]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[MrSubidubi]

Thanks for this!

Can you elaborate why this includes the Dockerfile langauage? Should the existing Dockerfile extension not suffice?

Also, I'd ask you to change your extension ID to tally-ls, tally-lsp or something similar, please.

[tinovyatkin]

Thanks for the review @MrSubidubi !

Bundled Dockerfile language: Zed's extension API, unlike VS Code's, doesn't provide a way for one extension to declare a dependency on another. Our LSP is registered for the Dockerfile language ID, but without either bundling the grammar or depending on the Dockerfile extension, users who install tally without the Dockerfile extension would end up in a broken state that's hard to debug — the extension silently does nothing.

Since there's no dependency mechanism to automatically prompt users to install the Dockerfile extension alongside ours, bundling the grammar (pointing to the same camdencheek/tree-sitter-dockerfile repo and commit) seemed like the safest way to guarantee a working out-of-the-box experience.

There's also a practical consideration: with the recent Docker language server integration in the Dockerfile extension (zed-extensions/dockerfile#35), tally and the official Dockerfile extension serve somewhat different roles. The Docker language server requires a running Docker daemon and is essentially docker build --check — great for build validation, but no language features like formatting or code actions. Tally is specifically designed to be daemon-free — we support Podman/Buildah registries.conf, re-implement BuildKit rules locally, and provide formatting, quick fixes, and fix-all code actions without any container infrastructure. So for users who prefer a lightweight setup (CI environments, Podman users, air-gapped systems), tally works as a standalone alternative rather than a companion to the official extension.

That said, if a dependency mechanism is added to the extension API in the future, I'm happy to drop the bundled grammar and use that instead!

Extension ID: Tally is first and foremost a linter and formatter — we followed the naming pattern of other linting/formatting extensions in Zed like ESLint, Prettier, and OXC, none of which use an -lsp suffix. LSP is just the integration protocol we use to push diagnostics; we don't provide traditional language features like "Go to Definition" or "Rename Symbol". Adding -lsp to the extension ID feels like exposing an implementation detail in the product name. Is this a new requirement for the registry? We'd prefer to stay with just tally if that's acceptable.