cargo-manifest-check

Check the formatting of your manifest files

cargo-manifest-check checks that various items from your manifest files are formatted as expected. It is currently mostly concerned with checking the order of items, and does not currently allow to automatically sort them. It may gain that ability in the future.

It is primarily intended for use in CI, and is relatively opinionated; it does not currently offer any kind of configuration.

Installation

In CI

With cargo-binstall

Pre-built binaries can be quickly obtained and installed using cargo-binstall:

cargo binstall cargo-manifest-check@<version>

where <version> is the version that should be installed. You might want to use the --disable-strategies option to disable some (or all) fallbacks.

With taiki-e/install-action

As taiki-e/install-action automatically falls back on using cargo-binstall, cargo-manifest-check can also be installed using the following workflow step:

- name: Install cargo-manifest-check
  uses: taiki-e/install-action@<action-version>
  with:
    tool: cargo-manifest-check@<version>

where <version> is the version that should be installed and <action-version> is the action's version to use.

From source

cargo-manifest-check can be installed from source through crates.io:

cargo install --locked cargo-manifest-check

Usage

Generalities

Once installed, cargo-manifest-check can be used as a Cargo subcommand as follows:

cargo manifest-check [paths...]

If paths are directories, they will be recursively searched for manifest files. If no paths are given, then the current working directory is searched. Hidden and .gitignored directories will not be searched. Manifests that contain the @generated marker will be ignored.

In a Text Editor

cargo-manifest-check features an output format intended for tool consumption, so it can be used as a linter in text editors. This format can be enabled by passing --short-format as a command-line argument.

Tools like efm-langserver allow to use cargo-manifest-check in LSP-enabled text editors. The following is an example of a suitable efm-langserver configuration:

tools:
  cargo-manifest-check: &cargo-manifest-check
    lint-command: 'cargo-manifest-check --short-format ${INPUT}'
    lint-formats:
      - '%f:%l:%c: %m'

languages:
  toml:
    - <<: *cargo-manifest-check

What is Checked

The following items are checked:

• Lexicographic ordering
  • Dependency sections
    • [workspace.dependencies]
    • [dependencies]
    • [dev-dependencies]
    • [build-dependencies]
    • [target.*.dependencies]
  • The workspace.members array
  • [patch.*] sections
  • features arrays in dependencies
  • Feature arrays in [features] sections, keeping dep: features grouped first
• Orderings as listed in Cargo's reference
  • Manifest keys and sections
  • [package] keys
  • [workspace.package] keys
• Workspace inheritance syntax
  • Dependency inheritance must use an explicit inline table (i.e., = { workspace = true }) instead of a dotted key (i.e., .workspace = true)

Dependencies can be grouped (by surrounding them with blank lines), in which case ordering is checked within each group individually.

See the tests/fixtures directory for examples of manifests that would be accepted/rejected.

What is not Checked

The following is not currently checked:

• Lexicographic ordering
  • Dotted dependency tables (e.g., [dependencies.foo])
• Orderings as listed in Cargo's reference
  • [profile.*] keys
  • target tables keys
• Workspace inheritance syntax
  • Package key inheritance must use a dotted key (i.e., .workspace = true) instead of an explicit inline table (i.e., = { workspace = true })

Support for these may be added later.

Additionally, cargo-manifest-check does not check that the manifest files are valid manifests (e.g., that keys exist and are valid); it only checks their formatting.

Compatibility

• If new checks are introduced which would reject manifests previously accepted, the SemVer version will be updated to reflect that.
• The default console output is however not intended for machine consumption and no compatibility guarantees are provided, as is the exact phrasing of error messages in the machine-parsable short format.

Contributing

This linter is opinionated on purpose and it is planned to limit configuration as much as possible. However if you have found some bugs regarding formatting checking or you think some other checks could be added (where one obvious order exists), please do open an issue.

License

Copyright 2024–2025 AudaciousAxiom

This project is licensed under MPL-2.0.