Convert to TypeScript

[jvilk]

After experimenting with TypeScript with Doppio, I have determined that it is very suitable for projects such as this one.

As a result, sometime later in the summer I will likely move to TypeScript. I do not anticipate that it will take longer than a week of work, and the payments for switching over will be worth the amount of churn required to perform the conversion.

List of benefits:

• Static guarantees that FileSystem implementations are appropriately defined to the interface.
• Easy support for customized library compilations that only contain the filesystems you will be using -- TypeScript knows your dependencies among files.
• Refactoring becomes tractable once we start increasing the amount of FS implementations.
• New contributors get compilation errors when they accidentally misuse an interface rather than silent failures.

[jvilk]

Current checklist (for typed branch):

Functionality:

• [x] Convert backends
• [x] Clean require polyfill / install functionality
• [x] Change library build step
• [x] Fix unit test code
• [x] Run unit tests
• [x] Fix boogs

Other:

• [x] Reintroduce comments -- JSDoc format

Git:

• [x] Make the master branch

[perimosocordiae]

I was thinking today that it might be worthwhile to write a post-mortem of our Coffeescript -> Typescript conversion efforts for Doppio and BrowserFS. I have a feeling that's the sort of thing HN/Proggit would enjoy.

[jvilk]

Yeah, I'd be willing to contribute to something like that; we should sketch out how we'd want to go about it.

Some things I'm noticing from the code-generation standpoint:

• Accidental return values / arrays.
• CoffeeScript defines extraneous variables for catch statements:

try
  # Code
catch error
  # Catch block

var error;
try {
  // Code
} catch (_error) {
  error = _error;
}

• Forward/backward loops in certain cases by default
• Extraneous iterator variable in loops (so you don't accidentally modify it)

for i in [0...3]
  # Body

var i, _i;
for (i = _i = 0; _i <= 3; i = ++_i) {
  // Loop body
}

• Using a block as a statement translates into a relatively expensive lambda
• CoffeeScript doesn't emit comments :frowning:

And then there are the other benefits of using TypeScript:

• Integration with module systems (so much better than catting)
• Compile-time checking of imports / typos / misc. syntax errors.
• Compile-time checking for DOM libraries and such in-the-box, and many others thanks to community typing efforts.
• Each class's stored state is made obvious from public/private fields.
• Hacks become extremely evident.
• Easy to define external interfaces that library users can pass to your library (e.g. file systems).
• Structural typing!

Some downsides:

• Dynamically constructing a class at runtime that meets the qualifications for an interface requires casting, which may be annoying to some.
• Cannot conditionally define methods and such for a class (e.g. cannot do if(IE) { public Method(){} } else { public Method() {} }).
  • Workaround: Subclasses for browsers.
• Not every library / DOM feature is typed yet -- but the community can help with this.
• Must use a module system: Some people may be OK with catting.
• Slow compilation -- but will eventually get better as they move forward to 1.0.
• No protected methods / fields; annoying for certain patterns.
• Interfaces and static methods: Can't really have static methods on interfaces due to how typing works.
• Some libraries are NOT fun to type (cough Node's file system cough).
• Overloaded functions are weird: Specify multiple function signatures for a function, but the last needs to encapsulate the types of all. Can't tell TypeScript that this last generalized signature is invalid for calling.
• TypeScript is not suitable for scripts (unless you generate JS first and run that).

[jvilk]

And I guess describing the classes of bugs we've found...