基于 Slack 反馈，我建议在 tools.deps 中支持简写命令。
这将类似于 Leiningen 中的“别名”或 NPM 中的“scripts”。但不是 tools.deps 当前的“别名”。
这将允许人们隐藏等等。
clj -X:graph graph :deps '"mydeps.edn"' :trace true :output '"trace"
后面
clj graph
在实施此方案后的一些用户命令示例
clj start ; Similar to npm
clj run ; Inspired by lein run
clj backend ; Step 1 ..
clj frontend ; Step 2 ..
clj devcards ; Step 3 of firing up a fullstack project with some extras.
它应该如何工作，我将留给实现者来决定。如果必须有保留的 run 或 start 来实现例如 clj run backend，那么就是这样。但越短越好。我所说的“简写命令”只是一个用来区分已被占用的“别名”的术语。
我认为这个小小的糖分会以几种方式清理它，我将在以下内容中尝试捕捉到这一点。
添加此内容的一些好处
- 很好地符合使用 Leiningen 和 NPM 等工具的知识
- 所有内容都在一个 deps.edn 文件中。
- 个人和公司可以有自己的约定，在整个项目中重用相同的简写，这使得知道如何启动一个项目变得非常简单。
- 项目文档和指南可以展示简洁的命令。
我知道 tools.deps 不打算取代 Leiningen，但它在 Clojure(script) 小社区中造成了一些碎片化，无论是故意的还是不是故意的，我的感觉是，它正在作为替换品使用，没有其他工具围绕它。当然，您仍然可以使用 lein，但似乎已经有足够多的人过渡到了这一点，它几乎成为必修课了。还有 Boot 以及可能还有其他工具，但我感觉用户群要小得多。
我可以应对并解决这个问题，但在编写这些长命令或记录项目时，我感觉到有某种退步。基本上，我在完成 deps.edn 的初始配置之后，似乎在任何高层次工作了一下。
一些接近目前 tools.deps 命令的方法
- 手动编写：当然可能，但需要更多的知识、经验、良好的记忆力，这取决于设置的复杂性和项目的相似性。
- 从 README.md 等处复制粘贴：工作得不错，但您必须参考文档，它使 Clojure 的复杂性看起来远远超过了它所需要的。
- Shell 脚本：将更多文件添加到项目中，比 deps.edn 自包含时传播信息更广。
- Shell 命令历史：在编码会话期间或连续多日工作时易于访问，但几周或几个月后则不易访问。
- 其他对此进行封装的工具。
因此，我并不是在说当前情况不可能管理，Clojure 似乎拥有比平均水平更高的技术熟练度用户群，但我认为它可以也应该更干净。我真的看不到有什么干净易读的操作会伤害到什么。当前的工作方式在我看来也有些精英主义。
虽然做出这个改进不会改变分裂，除非在极不可能的情况下完全取代 Leiningen，但至少会使两者更协调。
附加功能
也许它还应该支持在简写之后添加覆盖（例如，clj backend -M:foo），在同一个命令中执行多个简写（例如，clj backend frontend）或类似功能，但这目前并不是我强烈的看法。
我希望这些相对个人的观点足以解释为什么这可能是值得的。
最后，想象一下，在未来，如果你要给一个苹果用户开始使用一些非常好的全栈 Clojure(script) 工作做准备，你需要提供类似这样的所有说明。
brew install clojure
clj new re-frame/app my-app
cd my-app
clj start
这个请求不仅仅是在 tools.deps 中添加一些优雅的模板功能，它只是说明了非常流畅的体验可能是什么样子。从零开始，只需几步就能进入 Clojure(script) 开发的最高生产力体验将会很棒。当然，你不会立刻成为专家，但你可以从编辑文件开始，看到例如热代码重载功能直接工作。
