style: switch import granularity from "crate" to "module" (#435)

Co-authored-by: Claude <noreply@anthropic.com>

Author: KSXGitHub

.github/copilot-instructions.md

@@ -7,7 +7,7 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c
 - Commit format: Conventional Commits. Pattern: `type(scope): lowercase description`. The scope is optional.
 - Version releases are the only exception. The commit message is just the version number, such as `0.21.1`.
 - Write documentation, comments, and other prose for ease of understanding first. Prefer a formal tone when it does not hurt clarity, and use complete sentences. Avoid mid-sentence breaks introduced by em dashes or long parenthetical clauses. Em dashes are a reliable symptom of loose phrasing; when one appears, restructure the surrounding sentence so each clause stands on its own rather than swapping the em dash for another punctuation mark.
-- Prefer merged imports.
+- Prefer imports merged per module. Combine items from the same module into a single `use` statement, but write a separate `use` statement for each module rather than collapsing every path from a crate into one nested-braces statement.
 - Use descriptive names for generics, such as `Size` and `Report`. Do not use single letters.
 - Use descriptive names for variables and closure parameters. Single letters are permitted only in these cases: (1) conventional names like `n` for count or `f` for formatter; (2) comparison closures like `|a, b|`; (3) trivial single-expression closures; (4) fold accumulators; (5) index variables `i`/`j`/`k` in short closures or index-based loops; and (6) test fixtures with identical roles. Single letters are never permitted in multi-line functions or closures.
 - Use `pipe-trait` to chain through unary functions such as constructors, `Some`, `Ok`, and free functions. Use it to flatten nested calls and to continue method chains. Do not use it for simple standalone calls; prefer `foo(value)` over `value.pipe(foo)`.

AGENTS.md

@@ -7,7 +7,7 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c
 - Commit format: Conventional Commits. Pattern: `type(scope): lowercase description`. The scope is optional.
 - Version releases are the only exception. The commit message is just the version number, such as `0.21.1`.
 - Write documentation, comments, and other prose for ease of understanding first. Prefer a formal tone when it does not hurt clarity, and use complete sentences. Avoid mid-sentence breaks introduced by em dashes or long parenthetical clauses. Em dashes are a reliable symptom of loose phrasing; when one appears, restructure the surrounding sentence so each clause stands on its own rather than swapping the em dash for another punctuation mark.
-- Prefer merged imports.
+- Prefer imports merged per module. Combine items from the same module into a single `use` statement, but write a separate `use` statement for each module rather than collapsing every path from a crate into one nested-braces statement.
 - Use descriptive names for generics, such as `Size` and `Report`. Do not use single letters.
 - Use descriptive names for variables and closure parameters. Single letters are permitted only in these cases: (1) conventional names like `n` for count or `f` for formatter; (2) comparison closures like `|a, b|`; (3) trivial single-expression closures; (4) fold accumulators; (5) index variables `i`/`j`/`k` in short closures or index-based loops; and (6) test fixtures with identical roles. Single letters are never permitted in multi-line functions or closures.
 - Use `pipe-trait` to chain through unary functions such as constructors, `Some`, `Ok`, and free functions. Use it to flatten nested calls and to continue method chains. Do not use it for simple standalone calls; prefer `foo(value)` over `value.pipe(foo)`.

CLAUDE.md

@@ -7,7 +7,7 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c
 - Commit format: Conventional Commits. Pattern: `type(scope): lowercase description`. The scope is optional.
 - Version releases are the only exception. The commit message is just the version number, such as `0.21.1`.
 - Write documentation, comments, and other prose for ease of understanding first. Prefer a formal tone when it does not hurt clarity, and use complete sentences. Avoid mid-sentence breaks introduced by em dashes or long parenthetical clauses. Em dashes are a reliable symptom of loose phrasing; when one appears, restructure the surrounding sentence so each clause stands on its own rather than swapping the em dash for another punctuation mark.
-- Prefer merged imports.
+- Prefer imports merged per module. Combine items from the same module into a single `use` statement, but write a separate `use` statement for each module rather than collapsing every path from a crate into one nested-braces statement.
 - Use descriptive names for generics, such as `Size` and `Report`. Do not use single letters.
 - Use descriptive names for variables and closure parameters. Single letters are permitted only in these cases: (1) conventional names like `n` for count or `f` for formatter; (2) comparison closures like `|a, b|`; (3) trivial single-expression closures; (4) fold accumulators; (5) index variables `i`/`j`/`k` in short closures or index-based loops; and (6) test fixtures with identical roles. Single letters are never permitted in multi-line functions or closures.
 - Use `pipe-trait` to chain through unary functions such as constructors, `Some`, `Ok`, and free functions. Use it to flatten nested calls and to continue method chains. Do not use it for simple standalone calls; prefer `foo(value)` over `value.pipe(foo)`.

CONTRIBUTING.md

@@ -36,17 +36,16 @@ Automated tools enforce formatting (`cargo fmt`), linting (`cargo clippy`), and
 
 ### Import Organization
 
-Prefer **merged imports**. Combine multiple items from the same crate or module into a single `use` statement with braces rather than separate `use` lines. Import ordering is enforced by `cargo fmt`. Imports gated by a platform attribute such as `#[cfg(unix)]` go in a separate block after the main imports.
+Prefer **merged imports** at module granularity. Combine multiple items from the same module into a single `use` statement with braces, but write a separate `use` statement for each module rather than collapsing every path from a crate into one nested-braces statement. This granularity is enforced by the `perfectionist::import_granularity` dylint check (`style = "module"`). Import ordering is enforced by `cargo fmt`. Imports gated by a platform attribute such as `#[cfg(unix)]` go in a separate block after the main imports.
 
 ```rust
-use crate::{
-    args::{Args, Quantity, Threads},
-    bytes_format::BytesFormat,
-    size,
-};
+use crate::args::{Args, Quantity, Threads};
+use crate::bytes_format::BytesFormat;
+use crate::size;
 use clap::Parser;
 use pipe_trait::Pipe;
-use std::{io::stdin, time::Duration};
+use std::io::stdin;
+use std::time::Duration;
 
 #[cfg(unix)]
 use crate::get_size::{GetBlockCount, GetBlockSize};

cli/ai_instructions.rs

@@ -1,13 +1,11 @@
 use clap::Parser;
 use derive_more::Display;
 use pipe_trait::Pipe;
-use std::{
-    fmt,
-    fs::{File, read_to_string},
-    io::{self, Write},
-    path::{Path, PathBuf},
-    process::ExitCode,
-};
+use std::fmt;
+use std::fs::{File, read_to_string};
+use std::io::{self, Write};
+use std::path::{Path, PathBuf};
+use std::process::ExitCode;
 
 const SHARED: &str = include_str!("../template/ai-instructions/shared.md");
 const CLAUDE: &str = include_str!("../template/ai-instructions/claude.md");

dylint.toml

@@ -19,10 +19,8 @@ prefix = [
     "LowerHex", "UpperHex", "Octal",
 ]
 
-# The intended long-term style is "module". It is set to "crate" for now.
-# See https://github.com/KSXGitHub/parallel-disk-usage/issues/432.
 ["perfectionist::import_granularity"]
-style = "crate"
+style = "module"
 
 ["perfectionist::macro_argument_binding"]
 deny_extra = ["debug_assert_op", "debug_assert_op_expr"]

src/app.rs

@@ -2,22 +2,20 @@ pub mod sub;
 
 pub use sub::Sub;
 
-use crate::{
-    args::{Args, Quantity, Threads},
-    bytes_format::BytesFormat,
-    device::DeviceBoundary,
-    get_size::{GetApparentSize, GetSize},
-    hardlink,
-    json_data::{JsonData, JsonDataBody, JsonShared, JsonTree},
-    reporter::{ErrorOnlyReporter, ErrorReport, ProgressAndErrorReporter, ProgressReport},
-    runtime_error::RuntimeError,
-    size,
-    visualizer::{BarAlignment, ColumnWidthDistribution, Direction, Visualizer},
-};
+use crate::args::{Args, Quantity, Threads};
+use crate::bytes_format::BytesFormat;
+use crate::device::DeviceBoundary;
+use crate::get_size::{GetApparentSize, GetSize};
+use crate::json_data::{JsonData, JsonDataBody, JsonShared, JsonTree};
+use crate::reporter::{ErrorOnlyReporter, ErrorReport, ProgressAndErrorReporter, ProgressReport};
+use crate::runtime_error::RuntimeError;
+use crate::visualizer::{BarAlignment, ColumnWidthDistribution, Direction, Visualizer};
+use crate::{hardlink, size};
 use clap::Parser;
 use hdd::any_path_is_in_hdd;
 use pipe_trait::Pipe;
-use std::{io::stdin, time::Duration};
+use std::io::stdin;
+use std::time::Duration;
 use sub::JsonOutputParam;
 use sysinfo::{Disk, Disks};
 

src/app/hdd.rs

@@ -1,10 +1,8 @@
 use super::mount_point::find_mount_point;
-use std::{
-    ffi::OsStr,
-    fs::canonicalize,
-    io,
-    path::{Path, PathBuf},
-};
+use std::ffi::OsStr;
+use std::fs::canonicalize;
+use std::io;
+use std::path::{Path, PathBuf};
 use sysinfo::{Disk, DiskKind};
 
 #[cfg(target_os = "linux")]

src/app/hdd/test.rs

@@ -1,11 +1,9 @@
 use super::{DiskApi, FsApi, any_path_is_in_hdd, path_is_in_hdd};
 use pipe_trait::Pipe;
 use pretty_assertions::assert_eq;
-use std::{
-    ffi::OsStr,
-    io,
-    path::{Path, PathBuf},
-};
+use std::ffi::OsStr;
+use std::io;
+use std::path::{Path, PathBuf};
 use sysinfo::DiskKind;
 
 /// Fake disk for [`DiskApi`].

src/app/hdd/test_linux.rs

@@ -1,10 +1,8 @@
 use super::{FsApi, VIRTUAL_DISK_KIND, parse_block_device_name, reclassify_virtual_hdd};
 use pipe_trait::Pipe;
 use pretty_assertions::assert_eq;
-use std::{
-    io,
-    path::{Path, PathBuf},
-};
+use std::io;
+use std::path::{Path, PathBuf};
 use sysinfo::DiskKind;
 
 /// Test pure parsing of block device names — no sysfs dependency.