playcanvas/editor

TypeScript Support

marklundin opened this issue · 9 comments

marklundin commented

This ticket is to track the feature of TypeScript support to the editor as a native way of creating Scripts.

import { Script } from 'playcanvas'

export class My extends Script {
  /** @attribute */
  num : Number = 10

  /** @attribute */
  str : String = 'hello'
}

#Tasks

  • Support TS in Script attributes - playcanvas/attribute-parser#9
  • Support TS type stripping in launcher
  • Support TS in published/downloaded projects
  • Code Editor support
Maksims commented

What are the impacts on these:

  1. Debugging (source maps?)
  2. Script Save > Launcher Reload delay - can we save and refresh immediately, or will a delay occur before TS transpires?
  3. What is UX in Editor for this, how it impacts users, can they mix TS with JS, or they have to stick to one or the other?

Please provide more UX-related information on implementations for developers.

marklundin commented
  • Debugging (source maps?)

Source maps work across browsers

  • Script Save > Launcher Reload delay - can we save and refresh immediately, or will a delay occur before TS transpires?

This needs more testing, but around 100ms overhead for parsing something like this RXJS file including generating source maps. Results will be cached. This can also probably be improved

  • What is UX in Editor for this, how it impacts users, can they mix TS with JS, or they have to stick to one or the other?

Scripts can be created with either .js, .mjs or .ts defaults, indicating the type. All types can be used interchangeably within a project. For now .js would be default for all newly created scripts . Potential option for project level setting to default to a specific type for all newly created scripts.

  • 👍1
Maksims commented

This needs more testing, but around 100ms overhead for parsing something like this RXJS file including generating source maps. Results will be cached. This can also probably be improved

Larger projects consist of dozens and sometimes hundreds of script files, simple concatenation of JS files (classic scripts) takes a few milliseconds, TS transpilation will take seconds if not tens?

marklundin commented

There will be some unavoidable overhead/cost in opting in, but I wouldn't expect it to be anywhere near that.

mvaligursky commented

As long as the results are cached, and so only the changed files are transpiled, this sounds really great to me. It's not like there's a way to run TS files natively, so any workflow typescript developers use already involves some transpilation. Having it done natively by the Editor is a big deal.

I assume it will work the same way if they use the VSCode plugin to automatically sync ts files to our cloud?

marklundin commented

Yep, that should work to. I think TS devs currently transpile before syncing (which will still be possible), but they can also sync TS directly and rely on editor for transpilation.

mvaligursky commented

I wonder if we could kick off the transpilation process as soon as the user saves the .ts file in the editor. By the time he gets to launch it, it will likely be transpiled already.

Maksims commented

The UX has to be well implemented with the case of not-immediate results. For example if user saved a file, and server started transpilation, while user refreshes Launcher then there is a problem:

  1. If transpilation is not finished, user will load previous code, this will lead to frustrations. In fact - there is a case of files not saving in IDE sometimes, and it is not well communicated and apparent to user when refreshing Launcher why it is not loading most recent stuff.
  2. Throttling Luancher loading while transpilation is not finished - is not a way, as it will lead to long delays, and frustrate users even more.
  3. If user has created/pasted a new TS file in a project, so there is no cached transpiled version and user opens Launcher - then it will have to throttle or not load it? This should be well communicated also.

So definitely a few things need to be cleared out and well communicated:

  1. How long the transpilation take for various realistic sizes of TS files.
  2. What are the behaviours when no transpiled JS is available.
  3. What is the UX in Editor for parsing attributes while transpilation is in progress.
  4. Deep linking from Launcher into IDE on exceptions - will that still work?
marklundin commented
  • How long the transpilation take for various realistic sizes of TS files.

This file seems to be used in most benchmarks. Current tests is around 100ms on MBP M2, which is not 0, but likely only a small fraction of the time to load it.

  • What are the behaviours when no transpiled JS is available.

I believe this should never happen. If a file is requested, it should reflect the current state. There should not be a difference between the TS and JS. Realistically though, this will depend on how fast transpilation is in real world projects.

  • What is the UX in Editor for parsing attributes while transpilation is in progress.

Attribute parsing is on the TS itself and does not depend upon transpilation. See playcanvas/attribute-parser#9

  • Deep linking from Launcher into IDE on exceptions - will that still work?

I believe this should work due to the source mapping, but needs more investigation.

  • ❤️1