@Andy Checking in on your reply in Discord that you had some updates to the plugin and types to share. I would love to take a look at those. Perhaps setting up a public repo so others can contribute as well?
Thanks for the reminder!
Here's updated types and the plugin. I don't remember exactly what changed in the plugin, I think it was fixes for super() calls in constructors.
A public repo would be great, I'll look into getting that set up.
pdtsnew.zip (17.5 KB)
hey @andy, has the repo ever been created? I'd love to play around with this and potentially contribute.
I haven't, no. I'll zip up my latest types and plugin here again, since I've made some changes while developing a game with TypeScript over the past few months
There's not a great way to bundle this up in a package, so I've just put it in an example project like before.
The same shortcomings still exist:
Arguments to subclasses' constructors always get passed into the super()
call. So a class like:
class Sprite extends playdate.graphics.sprite {
constructor(x: number, y: number) {
super();
this.x = x;
this.y = y;
}
}
will incorrectly transpile to Lua that calls Sprite.super.init(self, x, y)
.
Default class exports don't work. so rather than doing
export default class Sprite extends playdate.graphics.sprite {}
you need to define
class Sprite extends playdate.graphics.sprite {}
and then export as
export default Sprite;
If you'd like to put this up anywhere, feel free to!
tstlexport 2.zip (27.8 KB)
Thanks, I'll have a look at it this week!
(And also check why the previous one barked about missing lua files, despite paths being correct, but I'll reply here again if it happens again)
Hey everyone!
I have been following this thread with great interest. I really like Typescript and use it daily, so being able to use it to create playdate games is a dream!
I have been collecting things from this thread and would like to create a repository for it, as well as create a set of NPM packages that would make the process easier. This message is mostly for asking for permission, given how much this thread has been of inspiration.
Something else I wanted to mention. The package I am creating will include some more utilities. One of them is a parser of the online documentation, which can be used to automatically create a playdate.d.ts
with all namespaces, functions, documentation, etc.
It works ok, but there is still some manual work needed, because the documentation doesn't obviously include any hint on the types being used (at least nothing that can be easily parsed by a machine). Parameter types can be deduced by context and naming, but return types require a human's intervention.
My question is — is there a resource I'm not finding that could help me improve this parser? It's a long shot, but there's no harm in asking. It could be anything really. I'm wondering if the actual implementation of the Lua SDK is written in C (I assume it is) in which case there might be C function signatures somewhere. But I might be very wrong about that.
(Edit: to be clear — this is not really crucial, but if there is an easy way to automate the creation of the d.ts
file, it would be a nice thing to have).
I'm not exactly ready to publish — but if @andy and @orta are fine with me putting this somewhere, I'll do it as soon as I can (I'm using Andy's exported files, and orta started the thread in the first place — but I can of course credit anyone else I am forgetting).
Sorry for the long post — thank you all for sharing your work
You have my permission, feel free to use the .d.ts and my class transformation plugin. The code for require transformations is orta's, though, so I can't speak to that.
Yeah, my code is your code
I am actually ready to publish what I have. There is one thing that is blocking that though.
The script I have crawls the SDK documentation, so the d.ts generation is sort of automatic. The only thing I did manually was fill in the types, often with Andy's d.ts as (irreplaceable) inspiration. The upside is that the generation can be run multiple times after tweaking the format of the generated file (I am using ts-morph). If newer versions of the SDK are released, the generator can use a previous version as base, and the generator will highlight things that must be checked (like "this function wasn't there, and now is there").
The scripts also grabs the description for each function, method, property, and callback from the SDK documentation.
This is pretty handy since you get the documentation in the IDE while coding. But, I'm pretty sure this is not allowed per the SDK license, unless I have permission from Panic. I might have to remove the docs depending on the answer (understandable).
Other than that, I added other changes, such as:
export default class
andexport class
are now supported- there is no need to import any
CoreLibs
file, they will be required automatically depending on the TypeScript code.
I am now looking at the issue with the Super
call from above. If you have other things that you would like to improve, let me know and I'll add them to my backlog.
Cheers!
Hey! I have received permission from Panic, so the repositories are now public.
The project is called "crankscript". Yes, that's the best I could do
You can find the main repository here. There is a starting template here.
You can also use the following commands to create a new project:
npx crankscript@latest new <name>
cd <name>
npm install
npm run simulator
Types should work automatically after this!
I like to use the command npm run simulator -- --watch --background
which will rebuild and rerun the simulator if the sources change. Note that --background
will only work on MacOS. For me, it is often useful to keep typing while I see the simulator being updated in the background every time I save.
I hope this is somehow useful. Feel free to contribute or open an issue in the repository if you want to propose an improvement or report a bug. My testing was limited so I'm sure there are still some issues.
I don't have a linux or windows machine to test this with, let me know if you have trouble with the project.