spotify-player 开发检查清单预发布流程与新增命令的扩展规范【免费下载链接】spotify-playerA Spotify player in the terminal with full feature parity项目地址: https://gitcode.com/GitHub_Trending/sp/spotify-playerchecklist.md是 spotify-player 仓库为贡献者维护的一份精炼开发检查清单覆盖“版本发布前该做什么”与“新增/修改命令时该同步哪些代码”两个高频场景。读懂这份清单并结合仓库源码你可以完整掌握该项目从代码改动到发布 crate 的交付链路以及如何正确地给这个终端 Spotify 播放器扩展一条新命令。清单定位两份面向开发者的内部约定仓库根目录的 checklist.md 全文很短但结构清晰分为两部分Pre-release checklist预发布检查清单4 个按序执行的发布步骤从版本号、代码检查、发布 crate 到创建 releaseCreating new commands创建新命令3 个必须同步修改的位置外加一条“修改命令时应遵循同样清单”的备注Note: should follow a similar checklist when modifying a command。清单中提到的每一个文件都能在仓库中一一对应下面逐项展开并结合源码说明每条要求背后的原因。预发布检查清单从代码改动到发布 crate 的完整链路第 1 步同步版本号main.rs与Cargo.toml清单第一条要求change theversionvalue defined inmain.rsandCargo.toml.即发布新版本时必须同时修改 spotify_player/src/main.rs 与 spotify_player/Cargo.toml 中的version值。以当前仓库为例spotify_player/Cargo.toml 中声明的版本为0.24.1。从源码结构看运行时对外展示的版本号实际来自 CLI 定义处的env!(CARGO_PKG_VERSION)见 spotify_player/src/cli/mod.rs这意味着 Cargo 包元数据是版本号的“单一事实来源”只要Cargo.toml更新编译产物中的版本号即随之更新。清单同时要求检查main.rs是为了确保两处声明保持一致避免版本信息在不同入口出现漂移。第 2 步运行cargo clippy静态检查并刷新依赖锁runcargo clippyto check the codes as well as to updateCargo.lock这一步有双重目的一是用 clippy 的 lint 规则做发布前的代码体检拼写、可疑写法、常见 Rust 反模式等二是确保 Cargo.lock 与当前依赖声明一致后再进入发布环节让发布产物与锁文件记录的可复现依赖树对齐。第 3 步在spotify_player目录执行cargo publishruncargo publishin thespotify_playerfolder to publish the package注意发布单元不是整个工作区而是工作区成员 spotify_player 这个 crate——它是终端应用本体的包名与发布目标包名spotify_player描述为 A Spotify player in the terminal with full feature parity。仓库同时提供了一个自动化发布脚本 scripts/publish它在执行cargo publish之前还会先同步主干分支核心逻辑为cd $( dirname -- ${BASH_SOURCE[0]} ) cd .. crate${1:-spotify_player} git checkout master git fetch git merge origin/master cd $crate cargo publish可以推断该脚本保证发布动作始终基于最新master代码执行且默认发布spotify_playercrate第一个参数可指定其他 crate 名。第 4 步创建新的 releasecreate a new release在 crate 发布成功后还需要到项目仓库的 Releases 页面创建一个新的 release填写对应版本号与更新说明让用户能通过 git 标签/发布页获取到与 crate 一致的版本交付物。创建新命令检查清单三处必须同步的位置spotify-player 的核心交互模型是“按键序列 →Command”。给应用新增一条命令例如新的页面跳转、新的播放控制时清单要求同步修改三处任何一处遗漏都会造成行为缺失或文档失实。位置 1Command枚举与Command::desc清单要求add new entries to theCommandenum defined incommand.rsand to theCommand::descfunctionCommand枚举定义在 spotify_player/src/command.rs是整个命令体系的类型源头#[derive(Copy, Clone, Debug, Deserialize, PartialEq, Eq, PartialOrd, Ord)] /// Applications command pub enum Command { None, NextTrack, PreviousTrack, ResumePause, // ... }新增变体时需注意两点变体可以携带数据。现有定义中已有多处带字段载荷的变体例如VolumeChange { offset: i32 }、SeekForward { duration: Optionu16 }、SeekBackward { duration: Optionu16 }新命令若需要参数也应沿用这一模式必须补齐desc()描述。Command::desc是一个对每个变体穷举匹配并返回人类可读说明的函数spotify_player/src/command.rs例如impl Command { pub fn desc(self) - String { // ... Self::Quit quit the application, Self::SwitchTheme open a popup for switching theme, Self::VolumeChange { offset: _ } unreachable!(), // ... } }由于该函数对枚举变体做了match全量覆盖新增变体后若不更新desc编译或运行期会立刻暴露遗漏——这正是清单把两处写在同一条目里的原因。对于带载荷的变体desc中常用format!生成动态文本或以unreachable!()兜底如VolumeChange。位置 2config/keymap.rs中的默认按键映射add a new default key mapping for the command inconfig/keymap.rs默认按键映射集中在 spotify_player/src/config/keymap.rs。其结构为/// Applications keymap configurations pub struct KeymapConfig { #[serde(default)] pub keymaps: VecKeymap, #[serde(default)] pub actions: VecActionMap, } /// A keymap that maps a KeySequence to a Command pub struct Keymap { pub key_sequence: KeySequence, pub command: Command, }KeymapConfig实现了Default其中按序构造了所有内置命令的默认映射例如n映射到Command::NextTrackspotify_player/src/config/keymap.rs。新增命令时应在该默认列表中加入对应的Keymap条目否则用户在未自定义配置时将无法触发新命令。位置 3更新 README 的命令表update the command table inreadme.mdREADME.md 中维护了一张完整的命令/按键对照表是终端用户对全部功能的第一索引。新增命令后必须把“按键 行为”写入该表保证文档与运行时行为一致。备注修改既有命令同样适用清单末尾的 Note 强调修改而非仅新增命令时也应走同一套检查清单——调整某个命令的默认按键需要改keymap.rs并同步 README改变命令语义则需同步desc文案与命令表描述。小结checklist.md 的价值在于把 spotify-player 两条最容易出错的开发链路固化为可逐项勾选的步骤场景涉及文件关键同步点预发布spotify_player/src/main.rs、spotify_player/Cargo.toml、Cargo.lock、scripts/publish版本号一致、clippy 通过、crate 发布、release 创建新增/修改命令spotify_player/src/command.rs、spotify_player/src/config/keymap.rs、README.md枚举变体 desc、默认按键映射、命令表文档三处同步这条“类型定义 → 默认配置 → 对外文档”的三步同步链路也是理解 spotify-player 命令体系扩展方式的最短路径。【免费下载链接】spotify-playerA Spotify player in the terminal with full feature parity项目地址: https://gitcode.com/GitHub_Trending/sp/spotify-player创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 spotify-player 开发检查清单：预发布流程与新增命令的扩展规范
spotify-player 开发检查清单预发布流程与新增命令的扩展规范【免费下载链接】spotify-playerA Spotify player in the terminal with full feature parity项目地址: https://gitcode.com/GitHub_Trending/sp/spotify-playerchecklist.md是 spotify-player 仓库为贡献者维护的一份精炼开发检查清单覆盖“版本发布前该做什么”与“新增/修改命令时该同步哪些代码”两个高频场景。读懂这份清单并结合仓库源码你可以完整掌握该项目从代码改动到发布 crate 的交付链路以及如何正确地给这个终端 Spotify 播放器扩展一条新命令。清单定位两份面向开发者的内部约定仓库根目录的 checklist.md 全文很短但结构清晰分为两部分Pre-release checklist预发布检查清单4 个按序执行的发布步骤从版本号、代码检查、发布 crate 到创建 releaseCreating new commands创建新命令3 个必须同步修改的位置外加一条“修改命令时应遵循同样清单”的备注Note: should follow a similar checklist when modifying a command。清单中提到的每一个文件都能在仓库中一一对应下面逐项展开并结合源码说明每条要求背后的原因。预发布检查清单从代码改动到发布 crate 的完整链路第 1 步同步版本号main.rs与Cargo.toml清单第一条要求change theversionvalue defined inmain.rsandCargo.toml.即发布新版本时必须同时修改 spotify_player/src/main.rs 与 spotify_player/Cargo.toml 中的version值。以当前仓库为例spotify_player/Cargo.toml 中声明的版本为0.24.1。从源码结构看运行时对外展示的版本号实际来自 CLI 定义处的env!(CARGO_PKG_VERSION)见 spotify_player/src/cli/mod.rs这意味着 Cargo 包元数据是版本号的“单一事实来源”只要Cargo.toml更新编译产物中的版本号即随之更新。清单同时要求检查main.rs是为了确保两处声明保持一致避免版本信息在不同入口出现漂移。第 2 步运行cargo clippy静态检查并刷新依赖锁runcargo clippyto check the codes as well as to updateCargo.lock这一步有双重目的一是用 clippy 的 lint 规则做发布前的代码体检拼写、可疑写法、常见 Rust 反模式等二是确保 Cargo.lock 与当前依赖声明一致后再进入发布环节让发布产物与锁文件记录的可复现依赖树对齐。第 3 步在spotify_player目录执行cargo publishruncargo publishin thespotify_playerfolder to publish the package注意发布单元不是整个工作区而是工作区成员 spotify_player 这个 crate——它是终端应用本体的包名与发布目标包名spotify_player描述为 A Spotify player in the terminal with full feature parity。仓库同时提供了一个自动化发布脚本 scripts/publish它在执行cargo publish之前还会先同步主干分支核心逻辑为cd $( dirname -- ${BASH_SOURCE[0]} ) cd .. crate${1:-spotify_player} git checkout master git fetch git merge origin/master cd $crate cargo publish可以推断该脚本保证发布动作始终基于最新master代码执行且默认发布spotify_playercrate第一个参数可指定其他 crate 名。第 4 步创建新的 releasecreate a new release在 crate 发布成功后还需要到项目仓库的 Releases 页面创建一个新的 release填写对应版本号与更新说明让用户能通过 git 标签/发布页获取到与 crate 一致的版本交付物。创建新命令检查清单三处必须同步的位置spotify-player 的核心交互模型是“按键序列 →Command”。给应用新增一条命令例如新的页面跳转、新的播放控制时清单要求同步修改三处任何一处遗漏都会造成行为缺失或文档失实。位置 1Command枚举与Command::desc清单要求add new entries to theCommandenum defined incommand.rsand to theCommand::descfunctionCommand枚举定义在 spotify_player/src/command.rs是整个命令体系的类型源头#[derive(Copy, Clone, Debug, Deserialize, PartialEq, Eq, PartialOrd, Ord)] /// Applications command pub enum Command { None, NextTrack, PreviousTrack, ResumePause, // ... }新增变体时需注意两点变体可以携带数据。现有定义中已有多处带字段载荷的变体例如VolumeChange { offset: i32 }、SeekForward { duration: Optionu16 }、SeekBackward { duration: Optionu16 }新命令若需要参数也应沿用这一模式必须补齐desc()描述。Command::desc是一个对每个变体穷举匹配并返回人类可读说明的函数spotify_player/src/command.rs例如impl Command { pub fn desc(self) - String { // ... Self::Quit quit the application, Self::SwitchTheme open a popup for switching theme, Self::VolumeChange { offset: _ } unreachable!(), // ... } }由于该函数对枚举变体做了match全量覆盖新增变体后若不更新desc编译或运行期会立刻暴露遗漏——这正是清单把两处写在同一条目里的原因。对于带载荷的变体desc中常用format!生成动态文本或以unreachable!()兜底如VolumeChange。位置 2config/keymap.rs中的默认按键映射add a new default key mapping for the command inconfig/keymap.rs默认按键映射集中在 spotify_player/src/config/keymap.rs。其结构为/// Applications keymap configurations pub struct KeymapConfig { #[serde(default)] pub keymaps: VecKeymap, #[serde(default)] pub actions: VecActionMap, } /// A keymap that maps a KeySequence to a Command pub struct Keymap { pub key_sequence: KeySequence, pub command: Command, }KeymapConfig实现了Default其中按序构造了所有内置命令的默认映射例如n映射到Command::NextTrackspotify_player/src/config/keymap.rs。新增命令时应在该默认列表中加入对应的Keymap条目否则用户在未自定义配置时将无法触发新命令。位置 3更新 README 的命令表update the command table inreadme.mdREADME.md 中维护了一张完整的命令/按键对照表是终端用户对全部功能的第一索引。新增命令后必须把“按键 行为”写入该表保证文档与运行时行为一致。备注修改既有命令同样适用清单末尾的 Note 强调修改而非仅新增命令时也应走同一套检查清单——调整某个命令的默认按键需要改keymap.rs并同步 README改变命令语义则需同步desc文案与命令表描述。小结checklist.md 的价值在于把 spotify-player 两条最容易出错的开发链路固化为可逐项勾选的步骤场景涉及文件关键同步点预发布spotify_player/src/main.rs、spotify_player/Cargo.toml、Cargo.lock、scripts/publish版本号一致、clippy 通过、crate 发布、release 创建新增/修改命令spotify_player/src/command.rs、spotify_player/src/config/keymap.rs、README.md枚举变体 desc、默认按键映射、命令表文档三处同步这条“类型定义 → 默认配置 → 对外文档”的三步同步链路也是理解 spotify-player 命令体系扩展方式的最短路径。【免费下载链接】spotify-playerA Spotify player in the terminal with full feature parity项目地址: https://gitcode.com/GitHub_Trending/sp/spotify-player创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考