Survey: TypeScript Language Support in the Editor

#1

Is there interest from the community to have transpiled TypeScript language support added to the Defold editor and build pipeline?

Current Approach

I’m one of the maintainers of the current ts-defold project. We provide a CLI for getting started and plenty of templates.

As it stands now, we provide support for writing TypeScript in external tools like VSCode, and we use the NodeJS runtime to transpile your TS code to Lua that Defold understands.

Hotkeys to build your project and hot reload aren’t part of the default template, but can be added to VSCode through an extension like Defold Buddy.

Pros

These features are all available and highly configurable thanks to TypeScript’s robust ecosystem of tools:

  • Static code analysis
  • Syntax highlighting
  • Linting
  • Autocomplete suggestions
  • Auto-formatting on save

Cons

  • Dependencies: you must install the Node runtime locally
  • Workflow: you need to use an external editor while writing code
  • Extensions: we support most popular Defold extensions, but the process isn’t automatic: as maintainers we have to produce, test, and maintain the type data ourselves

A Different Approach

It’s now theoretically possible for TypeScript to be integrated into the Defold editor and build pipeline. However, creating and maintaining such a project would require a chunk of time and effort (probably unpaid).

This integration would solve the 1st and 2nd issue in my list of cons for our current TS implementation.

Perhaps one day it could also fix the third issue, although I don’t think the Defold pipeline currently has the ability to provide accurate static type data for the Defold API and extensions (both Lua and native).

Feedback

To sum up, we currently having a working approach (via external tools like VSCode), but we could instead pursue tighter integration with the Defold editor. Do you find our current list of cons to be deal-breakers? Would you use TypeScript in your projects if it were integrated with the Defold editor?

5 Likes
#2

I don’t have anything particularly interesting to say, just answering the question.

No, I wouldn’t use TypeScript. I’ve found Lua to be sufficient for my needs.

3 Likes
#3

We provide static type data for the Defold APIs (example: API reference (gui)). Or are you referring to something else that is missing?

1 Like
#4

For me, I’m not interested in TypeScript supported although I’m quite familiar with it and JS. The more language supported, the more issues happens and also the less chances to get supported for those issues.

1 Like
#5

Thanks for the feedback. I don’t personally share this concern, because in this situation we’re talking about converting TypeScript to Lua before it is run. Defold doesn’t have to change the engine’s internals to support a transpiled language, it just has to run a step at build time to convert to Lua.

#6

I know but just imagine when someone has an issue when writting code in TypeScript, he raised it in the forum to ask for help. He will get very little support from community. The same for Lua when many people moving to writting code in TypeScript. I mean community support just like a cake is divided into smaller pieces. Maybe I’m overthinking but it could be that

4 Likes
#7

I’ll try to explain my goal and the pain points I’ve experienced while getting there.

When writing code in a transpiled language (eg. TypeScript or Teal), I’d like autocomplete and sound type checking for all of the following:

  • Defold API
  • Native extensions like DefOS
  • Lua libraries like DefMath

By sound type checking, I mean I’d like to know for certain what type of data I get from calling a method from any of the above sources. (Not just treating the type as unknown or any)

We have existing tools that parse the Defold docs, and script_api files to generate type definitions. But it’s never a perfect solution.

  • Some extensions don’t have a script_api at all (most Lua libraries)
  • There’s no strict validation for script_api files, so sometimes we have to guess at the author’s intentions (sometimes they write integer, but other times they write number; sometimes they make typos; sometimes they leave out types altogether)
  • Defold docs are fine for human readers, but challenging for tools to extract all the needed information. Eg. sometimes a property’s type is listed as just table, but to construct an accurate type definition, I need to know every property of that table, the types of those properties, and whether or not they’re optional. The comments usually explain in plain language what the table contains, but it’s challenging to extract accurate info from comments.

In a perfect world, the Defold build pipeline could smooth over all these issues and make it magically work with no manual intervention. But I’m not sure whether that’s possible.

#8

I’m only suggesting to parse the reference documentation in json format (which we also use for our own defold.com/ref pages and which I use when generating the docset for Dash.

I would like to improve the quality of the Defold API documentation so that it is near 100% correct in all cases. If you have examples of where we can improve it then please let me know!

What do you do in these kinds of situations? Can you set a type to unknown/any/object or similar ?

1 Like
#9

It will be cool if we have tighter TS integration, personally i will use it. Lua is nice to ofc )

1 Like
#10

How’s the experience debugging generated code, using breakpoints, viewing values of variable etc.? Is the Lua code easy enough to read and understand, and does it map cleanly to the TypeScript source?

The cons are not deal-breakers for me. Having written a bunch of Lua for my project already, I’m unlikely to make the switch though. I would be more inclined to switch to something like C# (powerful language and tools, and lots of open source projects). But then again, I don’t know TypeScript or its community, so I’m making assumptions.

1 Like
#11

No, never.

PS: You can create a poll if you want to. Just click on gear icon → Build Pool.

1 Like
#12

I don’t know our debugging experience as well as I should. We output sourcemaps so the line numbers in Lua can be mapped back to the correct spot in your TS source. I’m not sure how that would change if we pursued Defold editor integration.

If you write using language features present in both Lua and TypeScript, then the Lua code maps extremely cleanly.

If you start using non-Lua concepts like enums, it still works, but the code is a little uglier.

There’s no shortage of TS developers, tools, or open-source projects: there are twice as many TS repos on Github than C# repos. That said, I have no idea what percentage of those projects are related to gamedev, so C# probably does have the advantage in this industry.

Thanks for the suggestion. I think we do parse the JSON, but I’m obviously not as familiar with the code as I should be. I’ll review it carefully before providing any further feedback.

2 Likes
#13

A discussion in the Discord reminded me of another concern I had.

It appears that Teal is not supported in script or gui_script files. Each time you need to write a boilerplate to import it.

If this extends to all transpiled languages, I think it adds a couple complications:

  1. If you’re a newcomer who wants to use TS with Defold, you will still need to learn enough Lua to setup the boilerplate code (I realize you could learn this in minutes, but it’s still a cognitive barrier)
  2. Our current implementation doesn’t have this requirement (a example.script.ts file magically becomes a Lua example.script file when you save it), so switching to the way the Teal extension handles it would be a regression in user experience in this regard

Absolutely, although if you do that too often you lose the benefits of a strictly typed language.

There are some edge cases where we can’t operate without proper type data. For instance, Lua supports multiple return values from a function. TypeScript cannot natively handle that. So we need to know in advance the shape of data we’re getting and wrap it in the LuaMultiReturn keyword to handle that scenario.

Welcome to the forums!

#14

This will likely change at some point, but for now ignoring script files was the fastest way forward.

1 Like