根据Slack上的反馈，我提议在tools.deps中支持简写命令。
这将类似于Leiningen中的“别名”和NPM的“脚本”，但不是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）等，但对我来说这不是一个强烈的观点。
我希望这些相当个人的观点足够清楚地解释了为什么这可能是值得的。
最后，想象一下，在未来，如果你给Mac用户的是这样的所有相关指令，让他们从Clojure(script)中开始做一些真正棒的全栈工作。
brew install clojure
clj new re-frame/app my-app
cd my-app
clj start
这个请求不仅关于在tools.deps中添加一些优雅的模板功能，它只是展示了一个非常流畅的体验可能是什么样的。在这么少的步骤中从零开始，进入非常高效率的Clojure(script)开发将是很好的。不是说你马上就会成为专家，但你可以开始编辑文件，看到比如热代码重载就会这样工作。
