背景

今天，ETA是我最受欢迎的开源项目。但是，当我3年前我第一次出版时，它不是我的主要重点之一。实际上，我创建了ETA作为Squirrelly的纤细变化，这是一种更复杂的模板引擎，具有助手和过滤器等功能。

随着时间的流逝，我意识到，对于大多数项目而言，嵌入式模板引擎实际上比更复杂的东西更好。需要复杂或客户端HTML处理的项目通常使用React或Vue等框架。同时，ETA的性能和低捆的尺寸使其非常适合需要快速处理，低内存使用或处理非XML语言的项目。

同时，由于其速度，DENO的支持和句法优势，ETA变得越来越流行。考虑到这些因素，我决定将ETA成为我的主要重点。我花了一些时间编写教程，解决问题和抛光文档。

经过几年和一段时间的宣教录，我终于有时间再次从事ETA工作。我决定对项目进行一些重大更改，包括构建系统，API和文档。

构建系统更新

尽管ETA具有优势和功能，但它还是有一些大问题。一个问题是构建系统。复杂而笨拙，很难维护和更新。我处理了复杂的配置文件，以及针对Deno的版本进行转换的必要性。

版本3的更改：

使用microbundle捆绑库有助于我避免需要复杂的配置文件。
使用github操作进行测试和收集覆盖范围使我能够合并我使用的服务。
通过在tsconfig.json中设置allowImportingTsExtensions: true，我能够避免使用Denoify进行单独的deno构建。

API改变

另一个问题是API。像eta.render()这样的简单方法具有许多功能过载，使得难以推断和使用不直觉。当调用render，parse和compile等用户暴露功能时，可以传递自定义配置对象。实际上，这意味着每次调用任何这些功能时都必须将用户提供的配置与默认配置合并。

版本3的更改：

只有一个导出，一个名为Eta的命名类。该类有一个单个构造函数，该构造函数处理配置对象并在实例化时间内生成模板缓存。
render()和renderAsync()函数现在具有单个函数签名。
- 在ETA V2中，render()和renderAsync()可用于渲染命名模板或模板字符串。 ETA V3引入了两个新功能，以渲染模板字符串：renderString()和renderStringAsync()。
readFile()和resolvePath()函数（eta在内部使用）可以被用户覆盖为类方法。
每个编译模板内部的内部变量和方法存储在eta对象中，而不是在包括res在内的几个变量中。
用户不必允许用户指定一个root目录和多个views目录，而是只能指定一个views目录。该目录用作所有模板分辨率的根目录。所有模板文件都必须在此目录内部或该目录的子目录内，改善模板安全性并降低昂贵的文件lookup操作。

开发人员的经验变化

ETA V3的最大变化之一是增加了详细的运行时错误（受EJS的启发）。考虑以下模板，该模板会由于不确定的变量而投掷：

Template header
<%= undefinedVariable %>
Lorem Ipsum

ETA V2会在一些通用信息中丢下错误，但这并不是非常有用的。相比之下，ETA V3使用模板名称，行号和错误消息给出了详细的错误：

EtaError [ReferenceError]: .../my-dir/templates/runtime-error.eta:2
    1| Template header
 >> 2| <%= undefinedVariable %>
    3| Lorem Ipsum

undefinedVariable is not defined

文档更改

ETA V2的文档广泛，但很难导航。有关该项目的信息分为40+（！）文档页面，在分布在3个不同网站部分的多个文件夹中。

ETA V3的文档占用了9页，全部发现在网站的同一部分（eta.js.org）。单个页面涵盖了诸如模板语法和API概述之类的主题，而不是在多个页面上分开。

ETA的未来

我为ETA V3中的更改以及整个项目感到自豪。非常感谢那些通过公关，问题和建议为项目做出贡献的人。还要感谢像ejs这样的项目，ETA继续汲取灵感。

目前我认为ETA大多是功能完整的，尽管我将继续修复错误并添加一些小功能。我鼓励图书馆的现有用户升级到V3，我希望新用户会发现ETA非常适合他们的项目。

链接

如果您喜欢这篇文章，请不要忘记分享它，并在Twitter上的@nebrelbug上关注我。