Closed zoowar closed 7 years ago
It's not just Boot: CIDER, ProtoREPL and all sorts of other tools would need to be updated since those all look for build.boot
today. In addition, for backward compatibility, Boot -- and all those other tools -- would need to support both build.boot
and <something>.clj
going forward. That's a big ask.
I'd also note that some editors and tooling already recognize build.boot
as Clojure source code. ProtoREPL, for example, applies Clojure formatting and lets you evaluate forms from build.boot
just like regular source code.
I think you might instead want to log issues against those editors and tools that do not already support build.boot
today?
build.boot
is syntactically Clojure, and using a .clj
extension would indeed make editing easier for most people, because they wouldn't have to configure their editor to recognize .boot
files as Clojure syntax files.
But, build.boot
files are not semantically Clojure files, because they are loaded in the boot.user
, not user
, namespace. Many symbols are referred into boot.user
that are not referred by default into Clojure's user
namespace. So, it would be disingenous to call them .clj
.
We recommend users configure their editors to recognize .boot
files as Clojure syntax files in their editor configuration. In the editors I'm aware of, it's not hard.
Since the build.boot file is clojure code, consider changing the default BOOT_FILE from "build.boot" to "\<something>.clj" so that editors that select environments based on file extension can select clojure.
Code Reference