基于Sublime Text与Scala-cli的轻量级脚本快速开发与本地验证-sublime-PHP中文网

sublime text 报“command not found”是因为其构建系统不继承 shell 的 path 环境变量，即使终端中 scala-cli 可正常运行；解决方法是用 which scala-cli 获取绝对路径，并在自定义 build system 中显式调用该路径。

基于sublime text与scala-cli的轻量级脚本快速开发与本地验证

因为 Sublime Text 默认不读取你的 shell 环境变量（比如 $PATH），即使你在终端里能正常执行 scala-cli，Sublime 的构建系统也找不到它。

解决办法是显式指定可执行路径，而不是依赖环境变量：

先在终端运行 which scala-cli，得到类似 /usr/local/bin/scala-cli 或 /opt/homebrew/bin/scala-cli 的路径

在 Sublime 的构建系统（Tools → Build System → New Build System）中写死这个路径，例如：

{
  "shell_cmd": "/opt/homebrew/bin/scala-cli run "${file}"",
  "file_regex": "^(.*):([0-9]+):([0-9]+):\s*(.*)$",
  "selector": "source.scala"
}

scala-cli 默认只拉取中央仓库的发布版，但如果你正在开发一个尚未发布的库，或想验证本地修改，就得用 --dependency 或 --classpath 手动注入。

常见错误是直接写 --dependency org.scala-lang:scala-parser-combinators_2.13:2.3.0 却发现版本冲突或解析失败——这是因为 scala-cli 会自动推导 Scala 版本，而你没对齐。

Sublime Text Build Linux版

Sublime Text Linux x86-64 deb 安装包。官方也提供 rpm、tar.xz 和软件源安装方式。

下载

确认项目用的 Scala 版本：看 scala-cli 输出的 Using Scala 3.x 或 Using Scala 2.13.x，再选对应后缀的 artifact（如 _2.13 或 _3）
本地 jar 文件要用 --classpath /path/to/mylib.jar，不是 --dependency
如果依赖本身有 transitive 依赖，scala-cli 不会自动 resolve，得自己列全，或改用 scala-cli compile --include-deps 阶段验证

默认 scala-cli run 捕获了异常并做了美化输出，把原始行号和类名藏掉了，导致 Sublime 构建面板里只显示“Error”而没有具体位置。

关键是要绕过 scala-cli 的异常包装，强制 JVM 输出原生 stack trace：

在构建命令里加 -J-Dscala.cli.suppress.errors=false（适用于较新版本）
更通用的做法是改用 scala-cli compile + scala-cli run 分步：先编译确认无语法错，再运行；编译失败时 scala-cli 会输出标准 scalac 错误格式，Sublime 的 file_regex 才能正确高亮
如果用了 @main 方法但入口参数不对，错误可能被吞掉——这时在脚本开头加 println("START") 快速判断是否执行到那一步

scala-cli 默认启用缓存（基于文件内容 hash），但它不监听文件系统变化，Sublime 保存后不会自动触发 rebuild。你看到的“没更新”，其实是它复用了上次的 class output。

临时解决：每次改完手动加 --force，如 scala-cli run --force ${file}
长期建议：在构建系统里把 "shell_cmd" 改成 "shell_cmd": "rm -rf .scala-cli && /path/to/scala-cli run "${file}""，清掉缓存目录（.scala-cli）再跑
注意：删缓存会损失增量编译速度，日常开发可接受；CI 或批量验证时建议保留，靠 --watch 配合外部工具（如 fswatch）来监听

缓存路径默认在项目根下 .scala-cli，但如果你没在项目根打开 Sublime（而是单文件打开），scala-cli 会 fallback 到系统临时目录，导致清理失效——这点最容易被忽略。