3

假设我们在 2 个单独的文件中有 2 个简单的 TypeScript 类：

  • B.ts：
namespace A{
 export abstract class ItemBase {
  id:number=432;
 }
}
  • C.ts
///<reference path="B.ts"/>
namespace A{
 export class ItemType extends A.ItemBase{}
}
  • 并在 Code.ts 中调用代码：
///<reference path="C.ts"/>
let a:A.ItemType=new A.ItemType();

使用卡扣推动后一切正常

但是如果我将 C.ts 文件的名称更改为 AA.ts，我会收到错误消息：

TypeError: Cannot read property "prototype" from undefined. (row 14, file „AA”).

如果我不在 Code.ts 中实例化 ItemType 类，问题甚至会存在。

ts2gas 似乎在代码转译过程中没有考虑extends关键字，并将输出的 gs 文件设置为对应的 ts 文件顺序。因此，如果我们在扩展类文件之前命名扩展类文件（按字母顺序），我们会得到一个错误。

在开发过程中我是否必须注意 ts 文件名的正确顺序？我是否必须附加某种机制来处理 gs 文件加载顺序？当 gs 文件已经被转译时，这对我来说似乎是多余的。转译过程 (ts2gas) 应该注意以 TypeScript 方式使用的适当的类扩展策略。如果 ts2gas 可以使用原型将 TypeScript 类转换为 JS OOP，为什么它不能正确处理类扩展？

我想有一些更简单更好的方法。

4

1 回答 1

5

问题的根本原因之一是运行 Apps Script的Rhino v1.7R3.gs JavaScript 引擎以及组成一个脚本的许多文件的提升方式。

此外ts2gas，通过独立转换每个源文件，库的工作方式也有一些限制，并且可能在您的问题中起次要作用。

总而言之，您的脚本实际上是所有.gs文件的串联，按照它们在 Google Apps 脚本编辑器中出现的顺序排列。此订单通常是每个订单的.gs创建顺序。当@google/clasp用于将本地文件推送到脚本项目时，此顺序可能会更改为源文件名的字母顺序。

在您的示例中，.gs声明父类必须出现在任何子类声明之前（即提升问题）

为确保代码正确排序并避免这种情况，您有多种选择：

  1. 在单个文件中重新组合具有潜在提升问题的代码（从长远来看是笨拙和混乱的）
  2. 使用filepushorder您的选项.clasp.json来指定应首先推送哪些文件。（易于设置和维护）
  3. 有一个不同的项目构建链，以便更好地控制 Typescript 编译和精确的文件顺序（如有必要）。这是我设置的模板存储库以开始使用。

编辑

为了说明该filePushOrder选项的用法，我使用您的示例代码设置了一个示例存储库。

于 2020-01-19T11:41:02.097 回答