Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeScript Support #1195

Open
1 of 4 tasks
marklundin opened this issue Sep 11, 2024 · 9 comments
Open
1 of 4 tasks

TypeScript Support #1195

marklundin opened this issue Sep 11, 2024 · 9 comments
Assignees

Comments

@marklundin
Copy link
Member

marklundin commented Sep 11, 2024

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

@Maksims
Copy link
Collaborator

Maksims commented Sep 12, 2024

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
Copy link
Member Author

  • 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.

@Maksims
Copy link
Collaborator

Maksims commented Sep 13, 2024

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
Copy link
Member Author

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

@mvaligursky
Copy link

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
Copy link
Member Author

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
Copy link

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
Copy link
Collaborator

Maksims commented Sep 13, 2024

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
Copy link
Member Author

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In progress
Development

No branches or pull requests

3 participants