Let's say you have a file with a dependencies block at the end of it

With no newline at the end.

If you then run cargo-sort-ck -w it turns it into the following:

Which in turn breaks the TOML

The new workspace inheritance feature adds these fields. Would love for them to be sorted by this tool!

Looks like if there are comments in Cargo.toml, sorting doesn't work as expected.

Original

[dependencies]
actix-web = "2.0"               # Actix web
actix-rt = "1.1"                # Actix runtime
actix-identity = "0.2"          # Identity
serde = "1.0"                   # serialization
serde_json = "1.0"              # serialization for JSON
log = "0.4"                     # logging
env_logger = "0.7"              # logging
derive_more = "0.99"
futures = "0.3"                 # async
lazy_static = "1.4"             # runtime const evaluation
jsonschema = "0.3"              # JSON schema
rand = "0.7.3"                  # random value generator
uuid = { version = "0.8", features = ["v4"] } # UUID

argonautica = "0.2"  # argon2 password hashing
hmac = "0.9.0"       # for api token hashing
sha2 = "0.9.1"       # for api token hashing
hex = "0.4.2"        # for encoding the bytes from hmac to a postgres TEXT field

diesel = { version = "1.4.4", features = ["postgres", "chrono", "r2d2", "serde_json"] } # Database
chrono = { version = "0.4.11", features = ["serde"] } # time
dotenv = "0.15.0"                                     # environment variables
r2d2 = "0.8"                                          # Database pooling
diesel_migrations = "1.4"       # Embedding database migration

Print sort attempt

❯ cargo sort-ck -p
[dependencies]
# Actix runtime
actix-identity = "0.2"          # Actix web
actix-rt = "1.1"                actix-web = "2.0"               # UUID

argonautica = "0.2"  # Database
chrono = { version = "0.4.11", features = [ "serde" ] } # logging
derive_more = "0.99"
# for encoding the bytes from hmac to a postgres TEXT field

diesel = { version = "1.4.4", features = [ "postgres", "chrono", "r2d2", "serde_json" ] } # Database pooling
diesel_migrations = "1.4"       # time
dotenv = "0.15.0"                                     # logging
env_logger = "0.7"              futures = "0.3"                 # for api token hashing
hex = "0.4.2"        # argon2 password hashing
hmac = "0.9.0"       # runtime const evaluation
jsonschema = "0.3"              # async
lazy_static = "1.4"             # serialization for JSON
log = "0.4"                     # environment variables
r2d2 = "0.8"                                          # JSON schema
rand = "0.7.3"                  # Identity
serde = "1.0"                   # serialization
serde_json = "1.0"              # for api token hashing
sha2 = "0.9.1"       # random value generator
uuid = { version = "0.8", features = [ "v4" ] } # Embedding database migration

Everything else should go to stderr. For example:

$ cargo-sort-ck -p > Cargo.sorted.toml

This currently unexpectedly puts an invalid line at the top of the file. (Worse, the line contains color control characters.)

@DevinR528

Hello! Very cool tool. Currently trying to use it and getting an index out of range error.

❯ RUST_BACKTRACE=full cargo sort-ck
thread 'main' panicked at 'index 36 out of range for slice of length 29', /Users/casscool/.cargo/registry/src/github.com-1ecc6299db9ec823/toml-parse-0.2.9/src/sort/mod.rs:188:26
stack backtrace:
   0:        0x10fe2e96e - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h24bb64d98a7e25d6
   1:        0x10fe4b82c - core::fmt::write::h8fdc9cddb01cd8b2
   2:        0x10fe2c069 - std::io::Write::write_fmt::hcc3030013983bab6
   3:        0x10fe305c5 - std::panicking::default_hook::{{closure}}::h95817712c5ff0736
   4:        0x10fe30302 - std::panicking::default_hook::h34e085f4e0b1062d
   5:        0x10fe30b25 - std::panicking::rust_panic_with_hook::haf571858f996ac45
   6:        0x10fe306f2 - rust_begin_unwind
   7:        0x10fe5353f - core::panicking::panic_fmt::h11676ba6a846d9f4
   8:        0x10fe535a6 - core::slice::slice_index_len_fail::h501e6942b0a84a54
   9:        0x10fdc3c54 - toml_parse::sort::sort_toml_items::h45f2a25ab7d9b338
  10:        0x10fda3727 - cargo_sort_ck::check_toml::hf5300c0b3b350248
  11:        0x10fda4bf1 - cargo_sort_ck::main::h570d6b9dcca1a473
  12:        0x10fda0446 - std::rt::lang_start::{{closure}}::hf5e5b588b68a3ac9
  13:        0x10fe30def - std::rt::lang_start_internal::hcd84a36052901671
  14:        0x10fda4f09 - main

[package]
name = "api"
version = "0.1.0"
authors = ["Cassandra Fridkin <[email protected]>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
# Web server
actix-web = "3.0.0-beta.3"
# Error handling
anyhow = "1"
# Rust implementation of dataloader (https://github.com/graphql/dataloader)
dataloader = { version = "0.12", default-features = false, features = ["runtime-tokio"] }
# Rust really doesn't have logging in std
log = "0.4"
# But at least we can have pretty logging
pretty_env_logger = "0.4"
# Graphql server, currently undergoing major development
# so a lot of features are only available on master
juniper = { git = "https://github.com/graphql-rust/juniper" }
# Date and time library
chrono = "0.4"
# Connection pooling for databases
r2d2 = "0.8"
# Redis, including cluster and pooling support
redis = { version = "0.17", features = ["r2d2", "cluster"] }
# Cryptographic hashing library for passwords
sodiumoxide = "0.2"
# SQL but like...in rust. Originally I was using the Diesel ORM but
# honestly I kind of hate ORMs.
# Tokio runtime, macro support, etc.
sqlx = { version = "0.4.0-beta.1", default-features = false, features = [ "runtime-tokio", "macros", "postgres", "chrono", "ipnetwork", "tls" ] }
# URL parsing and handling
url = "2.1"

[dev-dependencies]
# I suspect eventually I'll use this
dotenv = "0.15"

Any ideas on what the issue is? I suspect it's somewhere in here, meaning this may actually be a bug with toml-parse. Thanks for your time!

How to reproduce

1. Download https://dist.apache.org/repos/dist/dev/iceberg/iceberg-rust-0.2.0-rc.1/apache-iceberg-rust-0.2.0-src.tar.gz
2. Run mkdir tmp && cd tmp && tar -xzf ../apache-iceberg-rust-0.2.0-src.tar.gz && cd apache-iceberg-rust-0.2.0-src
3. Run cargo sort -c -w

Then it reports "No file found at" error.

Investigation

I think the bug is in this line, since it considers any path which contains dots as file with extension.

If we rename dir name apache-iceberg-rust-0.2.0-src to anything without dots, it works fine.

Once #13 is merged the toml will be kept exactly as it was. It would be nice to be able to format this.

• Remove/keep trailing commas
• keep newlines between table
• remove newlines between key/values
• whitespace around = and after ,

Most cargo subcommands have a --workspace flag that applies them to all crates in the workspace, not just the root crate. However, it seems that cargo sort-ck currently only checks the root crate, and therefore needs to be invoked on every directory in the workspace. It would be nice if it also supported checking all crates in the workspace with just one command.

I'd like this project to ship pre-compiled releases.

Why?

We'd like to use this at CI, however, cargo install is much more costly than a single wget would be. Since CI is pretty much a constant repetition of the same scenario - it would be a ton of CPU cycles wasted if we compile cargo-sort every time.

Proposal

Automation. Would be nice if there was a Github Action at this repo, that would, for each Github release, run the build from the relevant tag and upload the built artifact to the release artifacts.
Then everyone will be able to download the releases at CI, and it won't be a burden to maintain the releases up to date.

Proposal

It would be nice to have a Dockerfile in the repository + workflow to automatically publish Docker images to Docker Hub.

This could be beneficial in a couple of ways:

1. Containerization.
2. A dedicated GitHub action could be created. (*)
3. Docker image could be utilized in GitLab CI.

I would like to work on a minimal Dockerfile if this is applicable.

I was trying to setup CI for one one my repo including cargo sort --check, but the check fail on Windows while it succeeds on Linux. I don't have a Windows machine so I cannot test this outside of the Github actions.

The repo is here. The logs of the failing job are here.

I don't know if you can see the logs, so here are the logs for ubuntu and windows.

I don't really know what more I can say, but if you need more input, I'll gladly answer.

As of recent, cargo-sort wants to remove lines before comments.

For example, cargo-sort requires that the following lines be removed to consider their enclosing Cargo.toml files sorted:

• https://github.com/trailofbits/test-fuzz/blob/67c8004af9cc6a295143dc537eb725cf44d06cc0/runtime/Cargo.toml#L11
• https://github.com/trailofbits/test-fuzz/blob/67c8004af9cc6a295143dc537eb725cf44d06cc0/test-fuzz/Cargo.toml#L29

I'd like an option, turning inline tables into normal tables, and vice versa.

So from

[dependencies]
serde = {version = "1", features = ["derive"]}

[dependencies.log]
version = "0.4"
features = ["std"]

to

[dependencies]
serde = {version = "1", features = ["derive"]}
log = { version = "0.4", features = ["std"]}

or

[dependencies.serde]
version = "1" 
features = ["derive"]

[dependencies.log]
version = "0.4"
features = ["std"]

Depending on the flag / config given.

Hi! Package maintainer for Arch Linux here.

cargo-sort is missing git tags for the last 2 releases (1.0.8 and 1.0.9), are you able to add these?

Much appreciated. :)

$ cargo-sort-ck -w path/to/first path/to/second ...

This would also play nicely with wildcard expansions provided by the shell:

$ cargo-sort-ck rust/src/*/Cargo.toml

@DevinR528

I'm trying to run cargo sort -g on this Cargo.toml :
https://github.com/PureStake/moonbeam/blob/master/node/cli/Cargo.toml

However it seems to completely ignore the groupings/newlines.
It is also not idempotent as running the command multiple times in a row keeps giving different outputs (no longer changes after 3 steps for this TOML).

Finally, it reorder lines only containing comments by looking at the text of the comment as if it was a key name. While it could make sense for a commented entry, it prevents to use comments to name each group.

Hello! First of all: I love this. Finally a cure for my obsessive lexicographic sorting :)

I tried cargo-sort-ck on https://github.com/mvdnes/zip-rs/blob/master/Cargo.toml#L15 and looking at the dependencies:

[dependencies]
flate2 = { version = "1.0", default-features = false, optional = true }
time = { version = "0.1", optional = true }
podio = "0.1"
bzip2 = { version = "0.3", optional = true }
crc32fast = "1.0"

they come out with an extra newline:

[dependencies]
bzip2 = { version = "0.3", optional = true }
crc32fast = "1.0"

flate2 = { version = "1.0", default-features = false, optional = true }
podio = "0.1"
time = { version = "0.1", optional = true }

Do you think there is any way to avoid that? I'd happily attempt a fix if you can give me some guidance.

First of all, thank you for this tool! It is really handy.

Unfortunately, it doesn't seems to work with cargo workspaces properly.

Given the workspace manifest:

[workspace]
members = [
  "first",
  "second",
  "third",
  "fourth",
  "fifth",
  "sixth",
]

Expected behaviour:

1. Sort members of the workspace Cargo.toml
2. Sort keys in Cargo.toml of workspace members

Actual behaviour:

• Workspace's manifest is corrupted:

[workspace]
members = [
"first",=
"second",=
"third",=
"fourth",=
"fifth",=
"sixth",=
]=

• Workspace crate's Cargo.tomls weren't analysed

member create .toml

[package]
name = "hello"
version.workspace = true
edition.workspace = true
license.workspace = true
repository.workspace = true

[dependencies]
anyhow.workspace = true
...

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: TomlError { message: "TOML parse error at line 3, column 8\n  |\n3 | version.workspace = true\n  |        ^\nUnexpected `.`\nExpected `=`\n" }', /Users/wangeguo/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-sort-1.0.9/src/sort.rs:113:46
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I find it a bit weird that currently to sort the dependencies in a Cargo.toml, the invocation is cargo sort-ck --write rather than just cargo sort (mirroring cargo fmt or cargo fix).

So I want to propose to rename this tool cargo sort and have it default to updating Cargo.toml with the current default behaviour being changed to a flag (cargo sort --check, similar to cargo fmt -- --check).

Tracked here DevinR528/toml-parse#3

Using the new workspace inheritance feature breaks the sorting

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: TomlError { message: "TOML parse error at line 3, column 8\n  |\n3 | version.workspace = true\n  |        ^\nUnexpected `.`\nExpected `=`\n" }', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-sort-1.0.7/src/sort.rs:113:46

Cargo-sort does not sort platform deps, i.e [target.'cfg(windows)'.dependencies]. Can we please address this?

Could cargo sort --check have an output format more similar to cargo check or cargo fmt --check? Currently it's not visually obvious why the command fails when it does. I think I would slightly prefer the cargo fmt --check behavior of only printing anything if there is an error, but having

Checking crate-a...
Checking crate-b...
Checking crate-c...
error! Dependencies for crate-c are not sorted.
Checking crate-d...

would also work (ideally with colors 😉)

I think there might be something slightly off with Cargo.toml discovery.

Based on this output from Ruma's CI run, it looks like cargo-sort is trying to parse examples/README.md as a TOML file:

thread 'main' panicked at 'called Result::unwrap() on an Err value: TomlError { message: "TOML parse error at line 3, column 7\n |\n3 | These are example projects showcasing how to use the various crates in this repository. You can use\n | ^\nUnexpected a\nExpected =\n" }', /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-sort-1.0.6/src/sort.rs:113:46

In this workspace, subdirectories under examples (examples/*) are set as workspace members.
I'm not sure, but maybe the examples folder is being considered a workspace member instead of the subdirectories of examples, and then it's using the only file in that directory as the Cargo.toml file?

We use cargo-sort in CI to check if entries are sorted but it would also be super helpful to validate if it has been formatted correctly. I suppose making -c return a non-zero exit code would be a breaking change, so perhaps some other option would be necessary.

When the exclude list in a workspace is not sorted, you get an error

error: Dependencies for [WorkspaceName] are not sorted

I suspect the same applies to the members list.

Hi! Thanks for the crate, it is really helpful.
I've found an issue: the app panics is there is a dotted keys defined in Cargo.toml.

Example:
Cargo.toml:

[package]
name = "testt"
version = "0.1.0"
edition = "2021"
metadata.key = "test"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

Actual behavior:

$ cargo sort ./Cargo.toml                                                                                                                                              1 ↵
Checking ....
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: TomlError { message: "TOML parse error at line 5, column 9\n  |\n5 | metadata.key = \"test\"\n  |         ^\nUnexpected `.`\nExpected `=`\n" }', /home/andreyons/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-sort-1.0.5/src/sort.rs:113:46
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behavior:

• The file is sorted.

Dotted keys are mentioned in TOML docs

Hi! Thanks for building this awesome tool! 😄 We're currently working on integrating it into our project at Aptos Labs.

A couple feature requests that might be useful:

1. --ignore flag to explicitly exclude certain directories or files from verification. We currently use the --workspace flag, but some of our cargo files are automatically generated (without ordering). It would be great to tell the tool to ignore these.
2. --custom-error-message flag to display a custom error message when the --check command fails. Instead of just displaying error: Dependencies for <crate> are not sorted. It would be nice to display a custom message, e.g., Dependencies for <crate> are not sorted. To sort them, run <command>. For more information, visit: <cargo-sort url>.

Running cargo install cargo-sort when the tool is already up-to-date, re-compiles and re-installs.

Expected behavior: it should not re-install.

I think you're running into this issue: rust-lang/cargo#8703.

This issue effectively disables using CI caching for this tool, since instead of re-using the existing cached install it will always re-install from scratch.

With Cargo.toml as

[dependencies]
amq-protocol = "6"
anyhow = "1"
bytes = "1"
diesel = { version = "1.4", features = ["postgres"] }
dotenv = "0.15.0"
lazy_static = "1"
regex = "1"
serde = "1"
tokio = {version="1", features=["net", "io-util", "rt", "macros", "rt-multi-thread"] }

[dev-dependencies]
celery = "0.4.0-rcn.11"
simplelog = "*"

[package]
edition = "2021"
name = "cavalcade"
version = "0.1.0"

and tomlfmt.toml as

table_order = ["package", "dependencies", "dev-dependencies"]

it gets reordered to

[package]
edition = "2021"
name = "cavalcade"
version = "0.1.0"
[dependencies]
amq-protocol = "6"
anyhow = "1"
bytes = "1"
diesel = { version = "1.4", features = ["postgres"] }
dotenv = "0.15.0"
lazy_static = "1"
regex = "1"
serde = "1"
tokio = { version = "1", features = ["net", "io-util", "rt", "macros", "rt-multi-thread"] }

[dev-dependencies]
celery = "0.4.0-rcn.11"
simplelog = "*"

Note the newline at the top of the file, and the lack of newline before dependencies

When invoked as a subcommand, cargo sort-ck fails because of how cargo passes on the command name as an argument:

"When Cargo invokes a custom subcommand, the first argument to the subcommand will be the filename of the custom subcommand, as usual. The second argument will be the subcommand name itself. For example, the second argument would be ${command} when invoking cargo-${command}. Any additional arguments on the command line will be forwarded unchanged."

https://doc.rust-lang.org/cargo/reference/external-tools.html#custom-subcommands

╰─$ cargo sort-ck                                                                                                                                                                                     101 ↵
Failure: No file found at: sort-ck/Cargo.toml

Is there a way to make the arguments to cargo-sort-ck consistent with how cargo passes them to subcommands?

When sorting groups, if first element wasn't sorted, it will be moved to previous group.

E.g.:

 # Logging
 tracing = { workspace = true }
 tracing-subscriber = { workspace = true, features = ["env-filter", "json"] }
+barter-integration = { workspace = true }
 
 # Service
 prost = { workspace = true }
 prost-types = { workspace = true }
-tonic = { workspace = true, features = ["transport"] }
 reqwest = { workspace = true, default-features = false }
+tonic = { workspace = true, features = ["transport"] }
 tower-http = { workspace = true, features = ["cors"] }
-barter-integration = { workspace = true }

I'm using cargo-sort-ck in my CI pipelines. Only now I learned that it was renamed to cargo-sort. I would have been grateful if I would could have somehow learned about that earlier.

One way to notify users stuck with cargo-sort-ck would be to make a new cargo-sort-ck release with a binary that prints some info about the rename and the link to https://crates.io/crates/cargo-sort and exits with a non-zero code. That would make the CI pipelines of those users fail and they would notice.

Looking at the download stats from https://crates.io/crates/cargo-sort-ck it seems worth to notify those users.

In a cargo workspace, running cargo sort --workspace seems to use workspace.members to find directories with crates that belong to the workspace, without also checking workspace.exclude for ones that match a pattern in workspace.members but are not meant to be the workspace anyways.

When my account was compromised a spam issue was created in this repo. I sincerely apologize. Cleaning up such issues via script.

e.g. make tokio = { version = "1", features = ["net", "io-util", "rt", "macros", "rt-multi-thread"] } become
tokio = { version = "1", features = ["io-util", "macros", "net", "rt", "rt-multi-thread"] }

Recently cargo added the ability to specify lints in Cargo.toml. Those seem like good candidates to add to the list of tables to sort.

[package]
name = "placeholder-name"
version = "0.1.0"
edition = "2021"
[dependencies]
axum = { path = "../../axum" }
hyper = { version = "0.14", features = ["full"] }
tokio = { version = "1", features = ["full"] }

is not considered sorted when running cargo sort --workspace --grouped --check, while the same snipped with a trailing newline is.

Version

Run with cargo-sort v1.0.7

The releases for cargo-sort seem to out of sync, e.g. crates.io: 1.0.6, GitHub releases/tags: 1.0.5.

Any chance of a tag being uploaded? Thanks! :)

The current stable release version 1.0.9 fails with this error message:

$ cargo install cargo-sort
…
$ cargo sort -w           
Checking rust...
Finished: Cargo.toml for "rust" has been rewritten
Checking mycrate...
thread 'main' panicked at /Users/shaun.jackman/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cargo-sort-1.0.9/src/sort.rs:113:46:
called `Result::unwrap()` on an `Err` value: TomlError { message: "TOML parse error at line 13, column 6\n   |\n13 | serde.workspace = true\n   |      ^\nUnexpected `.`\nExpected `=`\n" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

and this issue is fixed on the current main branch. Please tag a new stable release. Thank you!

The workaround is to install cargo-sort from Git:

cargo install --git=https://github.com/DevinR528/cargo-sort --branch=main cargo-sort

I presume this is intended behavior. I decided to document it in this issue as a reference. Please close it per your consideration.

Given example Cargo.toml:

[dependencies]
dirs = "1.0.2"

mio = "0.6"

Running cargo-sort-ck will output unexpected error:

Failure: TOML parse error: Invalid token in table, found "\'\\n\' or \'\\r\\n\'"

Given fixed example:

[dependencies]
dirs = "1.0.2"
mio = "0.6"

Running cargo-sort-ck will output:

Success: dependencies are sorted for "<redacted>/Cargo.toml"