协议化对文件系统的编译器访问

Question

当前构建基于磁盘上的文件。我们希望能够得到基于内存的构建、基于WebDAV的构建、基于S3的构建等。许多这些替代策略不在ClojureScript编译器的范围内，但这并不意味着我们不应该为用户提供所需的钩子以控制行为。

Answer 1

评论者：thheller

最近打开的一些问题（CLJS-900、CLJS-851、CLJS-899等）与我最近在shadow-build中（链接：1）所做的工作有所重叠。内存构建实际上已经可能，因为只有在被要求时才会接触到磁盘，尽管API可能需要一些清理。

无论如何，可能会有价值协调这些努力，让CLJS对每个人来说都更加易用。

(链接：1) https://github.com/thheller/shadow-build

Answer 2

评论者：alandipert

我也认为从不同位置获取源代码的构建会更加棒。

在这个意义上，我一直在考虑的一种替代方法是“SourceSet”方法。其想法是，而不是通过协议直接教会CLJS如何消费各种位置，提供一个用于构建“SourceSet”值的API，以及一个以SourceSet为输入的构建函数。我设想最简单的SourceSet是一个表示命名空间到字符串源映射的映射。

有了表示来源的值，第三方工具在调用编译之前可以无需了解或关注CLJS内部情况进行消费/发射/转换这些值。反过来，CLJS也不必关心SourceSet是如何构建的。

整个想法是受boot的FileSets启发的，它们基本上工作方式相同，但无法假设“它适合内存”。

Answer 3

参考资料： https://clojure.atlassian.net/browse/CLJS-901（由dnolen报告）