TypeScript classes order in Google AppScript Project

Question

Suppose we have 2 simple TypeScript classes in 2 separate files:

• 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{}
}

• and invoking code in Code.ts:

///<reference path="C.ts"/>
let a:A.ItemType=new A.ItemType();

Everything works well after pushing it using clasp

But if I change the name of the C.ts file to AA.ts, I would get the error:

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

The problem even exists if I would not instantiate the ItemType class in Code.ts.

It seems that ts2gas doesn't take into consideration the extends keyword during the code transpiling and sets the output gs files as corresponding ts files order. So if we name the extended class file before the class file that we were extending from (in alphabetical order) we would get an error.

Do I have to take care of proper order of ts filenames during development? Do I have to attach some sort of mechanism that takes care of gs file loading order? It seems to be redundant for me while the gs files have been already transpiled. The transpilation process (ts2gas) should take care of proper class extension strategy that was used in TypeScript manner. If ts2gas can transpile the TypeScript Class into JS OOP, using prototyping, why it can't handle the class extensions properly?

I suppose there's some simpler and better way.

Answer 1

One of the root cause of your issue is the Rhino v1.7R3 JavaScript engine which runs Apps Script and the way the many .gs files making up one script are hoisted.

Also the way ts2gas library works, by transpiling each source file independently, has some limitations and may play a minor role in your issue.

To summarise, your script is effectively the concatenation of all your .gs files, in the order they were appear in the Google Apps Script editor. This order is usually the order each .gs was created. When using @google/clasp to push your local files to your script project, this order is likely to change to the alphabetical order of your source filenames.

In your example, the .gs declaring the parent class must appear before any declaration of children classes (i.e. the hoisting issue)

To ensure proper ordering of your code and avoid this, you have several options:

1. regroup code with potential hoisting issue in a single file (clumsy and messy in the long run)
2. use the filepushorder option in your .clasp.json to specify which files should be pushed first. (easy to setup and maintain)
3. have a different project build chain for finer control of Typescript compilation and precise file order (if necessary.) Here is the template repository I have setup to get started.

EDIT

To illustrate usage of the filePushOrder option, I have setup a sample repository with your sample code.

Answer 2

Indeed, as @PopGoesTheWza indicated in the accepted answer, the alphabetical ordering of your files makes a difference. During my testing, I simply renamed my abstract class from MyClass.gs to aMyClass.gs, directly from the App Script editor and that didn't work.

So I went back to my Visual Studio project to rename it there and wondered if using a subfolder that started with a, would work. So I created an /Abstract folder and moved the MyClass.ts file in there. That did the trick in my case.

That solution seemed much more elegant, so I've just started using that pattern for any abstract classes I develop in the future.

Admittedly, there may be more nuanced problems that this does not solve. An abstract class that extends another abstract class, for instance. Then you could still run into this problem. But if your class structure is that complex, you should probably expect to deal with a little file ordering strategy from the start.