Consider using TypeScript
fgblomqvist opened this issue · comments
With risk of a déja vu (@peterklingelhofer knows what I'm talking about), I'd strongly recommend you guys to consider using TypeScript for this project, because it makes it so much easier for new and random contributors to get started. Working on non-typed code can be incredibly frustrating if you're not very familiar with it, and you're often left with spending large chunks of your time just understanding what objects various functions expect. Not to mention the time you save not having to debug your own code.
If nothing else, if a decision has already been made against it, it would probably make sense to document that somewhere (like in this thread), because I can guarantee you I won't be the first to bring it up 🙂
But great initiative restarting this project, much needed 🚀
Hey @fgblomqvist!
All three of the main devs (@peterklingelhofer , @mattburnett-repo , and myself, currently) I think are in alignment that we ultimately want to see this codebase in TypeScript. However, right now we're focusing on combining the existing JavaScript APIs (as outlined in the Active Development section of the docs and further elaborated on in the forum here and here.
A significant part of this work is learning what the API does, and to make sure that it continues doing this correctly. So there's been a lot of focus on migrating functionality, writing tests, etc.
Once we know what we've got, I think @peterklingelhofer would love to take a crack at starting a TypeScript conversion ;) (I'd personally prefer to have that happen fairly incrementally rather than all in one go, but tests will help catch any mishaps, and ultimately it's up to the person taking it on).
Thanks for the elaborate response, sounds reasonable! Hoping to contribute some day, but figured I'd at least drop this note sooner rather than later since it might help with the migration (writing types is kinda like writing tests at the end of the day), and it solves issues like #21. But understandable if you'd rather wait!
Hallo
Hard agree on everything mentioned by everyone already. Anything I would add to the discussion is some form of 'me too' comments, so I'll just leave it at that.
By yeah, I want to go to the TypeScript party too!
btw is there a reason you guys are doing CJS instead of ESM? Will make the migration to TS a bit more of a pain, no matter if it happens now or in a year
@fgblomqvist We're combining code from a bunch of different repositories into one. This isn't a clean rewrite, so there's a lot of legacy code that none of the currently active devs actually wrote (or even might not know exists). If you think there's a better way to do something, you are welcome to propose it (especially if you're willing to help implement it, or even just give pointers on how!).
Edit: and to clarify and actually answer your question, no, there isn't a reason :)
Ah okay, wasn't sure that was the case (copy/paste) but suspected it. Should be possible to do ESM file-by-file by changing the extension to .mjs to convert on-the-go (or for any further files you're bringing over, if you don't mind changing the imports to ESM style) 🙂
In terms of contributing, I'll see if I can try to help out with one of the open issues next week
If you want to make a ticket for the conversion and put in an example PR that would be greatly appreciated!
https://www.typescriptlang.org/tsconfig#JavaScript_Support_6247
Gradual migrations are definitely feasible, and quite common at a few places I previously worked at with lots of legacy code.
Api/beam have hit feature parity with live, so definitely worth tackling this/considering this high priority. Related: #169