Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

CLI command naming is inconsistent

未关闭
#41 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
38/100
Issue 类型
重构
描述清晰度
基本清楚
活跃度
冷清
技术栈
javascript
领域
cli, documentation

调研方向

首先检查 CLI 命令的实现,尤其是手动实例路由和 lib/commands/stack/local-setup.js,然后比较列出的命令模式。检查 README 和现有的 --help 行为;完成的标准是约定已经达成一致、instance 使用子命令、php-logs 已弃用,并且文档反映已接受的更改。

由索引模型根据 Issue 内容生成。

描述

to refine

As the CLI has grown, naming patterns have diverged. This tracks the inconsistencies so we can agree on conventions going forward.

Two patterns for multi-action resource commands

Some resources use a single command with as a positional arg:

app variables <list|get|set|delete> [app]
app domains <list|add|remove|retry> [app]
app ip-list <get|set> [app]
app ua-blocklist <get|set> [app]
app tasks [list|cancel|logs]
Others use separate named commands per operation:

app deploy (create) vs app deploys (list)
app build (create) vs app builds (list)
app backup (create) vs app backups (list)
These are equivalent patterns for the same kind of CRUD operation.

Action vocabulary isn't standardised

add vs create, remove vs delete, set vs update are used interchangeably across commands with no rule for which to pick.

instance uses a non-standard flat positional chain

instance [group] [action] [id] [value]
All other commands use yargs subcommands. The instance routing is manual if/else, which breaks per-subcommand --help and causes the target argument to shift position:

instance info — id is in the action slot
instance access list — id is in the id slot

php-logs is redundant

stack php-logs duplicates app logs --type php. The dedicated command adds noise.

build-cache only accepts one value

build-cache requires a positional action but only accepts clear. It should just be build-cache clear.

local-setup is undocumented

lib/commands/stack/local-setup.js exists but is not listed in the README. Either document it or remove it.
Mark php-logs as deprecated

For Altis Team Use

Acceptance Criteria
  • Agree on a standard CRUD pattern (suggest: plural noun + action subcommand - deploys list, deploys create)
  • Agree on action vocabulary (list, get, create, update, delete, with add/remove only for membership)
  • Refactor instance to use proper yargs subcommands
  • Document agreed conventions in README or CONTRIBUTING
  • Mark php-logs as deprecated
Ready for Work Checklist

Is this ticket ready to be worked on? See
the Play Book Definition of Ready

  • Is the title clear?
  • Is the description clear and detailed enough?
  • Are acceptance criteria listed?
  • Have any dependencies been identified? (Optional)
  • Have any documentation/playbook changes been identified? (Optional)
  • Is an estimate or time box assigned?
  • Is a priority label assigned?
  • Is this ticket added to a milestone?
  • Is this ticket added to an epic? (Optional)
Completion Checklist

Is this ticket done? See
the Play Book Definition of Done

  • Has the acceptance criteria been met?
  • Is the documentation updated (including README)?
  • Do any code/documentation changes meet project standards?
  • Are automatic tests in place to verify the fix or new functionality?
    • Or are manual tests documented (at least on this ticket)?
  • Are any Playbook/Handbook pages updated?
  • Has a new module release (patch/minor) been created/scheduled?
  • Have the appropriate backport labels been added to the PR?
  • Is there a roll-out (and roll-back) plan if required?
主要语言
TypeScript
星标
0
派生
2
平均合并
16 小时 6 分钟
30 天内合并 PR
7

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

humanmade/altis-cli 的其他 Issue

查看 humanmade/altis-cli 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。