search

collective-soundworks / soundworks

Creative coding framework for distributed applications based on Web technologies.
http://soundworks.dev
BSD 3-Clause "New" or "Revised" License
114 stars 7 forks source link

Support TypeScript #29

Open schlenger opened 3 years ago

schlenger commented 3 years ago

Since we've worked with your framework in the past and also had some projects where TypeScript turned out quite handy, we wanted to combine both things. While getting started with this, a few things came up and we decided that it'll probably make more sense to ask this directly:

1) Was this planned or on any roadmap before? 2) Have you started or are you interested in creating a @types repository for the core itself? 3) Where is a good place to start? We thought at the soundworks-template directly. However, we stumbled upon the segmentation between the application core and the build repository, which makes things really tricky if you don't have the overall overview. Any advices here?

We're keen to support you with this, if you are also interested in it - if not a bit of feedback on "how to best migrate the soundworks-template" or on "how to integrate soundworks in a new project would be helpful. Thank you.

b-ma commented 3 years ago

Hi,

Thanks for the suggestion,

Typescript support is not in the roadmap and I've never tried anything in this direction, but I've nothing against the idea. If you are interested in digging this I would be happy to help the best I can (being completely honest that I'm really not a typescript user), but I thing I need to understand better what you want to achieve.

My first impressions/understanding are there are two different problems:

  1. Adding types to the core would be quite easy I guess, but probably difficult to maintain in the long term because of the kind of duplication between the typescript types and the jsdoc comments, is this possible to generate the types file from jsdoc?
  2. Modifying the soundworks-template to support typescript on the application side could be quite straightforward I guess. Indeed this should probably be done in the soundworks-template-build. This build stuff is mainly a wrapper around webpack so I guess there wont be any problem in integrating typescript build. For example, we have already forked that to support vue.js (there). I would go for the same kind of solution in a short time perspective, 1. fork the soundworks-template-build, 2. modify to handle typescript and 3. import the modified version in your application. I agree this is kind of a brute force solution, but it should work and could give hints on how to design a more robust and maintainable approach (yeoman generator, etc.).

Let me know your thoughts about that

schlenger commented 3 years ago

Typescript support is not in the roadmap and I've never tried anything in this direction, but I've nothing against the idea. If you are interested in digging this I would be happy to help the best I can (being completely honest that I'm really not a typescript user), but I thing I need to understand better what you want to achieve.

Okay, thanks for the information.

1) Yes, the redundant code will be hard to maintain. I haven't created a @type package myself, but I can check it out. I guess I've seen an option to create actual TypeScript code according to the jsdocs - maybe we can use this. 2) This also sounds good - Migrating the soundworks-template would be enough for the first step. I was just a bit confused of the split approach for the build tool, thanks for the explanation. If you got any more feedback how to dive deeper into the architecture, this would be very appreciated.

We can keep this issue open to collect the updates.

b-ma commented 3 years ago
  1. Yes, the redundant code will be hard to maintain. I haven't created a @type package myself, but I can check it out. I guess I've seen an option to create actual TypeScript code according to the jsdocs - maybe we can use this.

ok cool, let me know what you find

  1. This also sounds good - Migrating the soundworks-template would be enough for the first step. I was just a bit confused of the split approach for the build tool, thanks for the explanation. If you got any more feedback how to dive deeper into the architecture, this would be very appreciated.

Yes, the approach is kind of weird but really handy when it comes to maintaining several applications. I will try to write a post explaining the scope of each building blocks and their relation, it should be useful for other people as well.

We can keep this issue open to collect the updates.

No problem

schlenger commented 3 years ago

Hey,

I've tried out the first steps and the updated build tool can be found here: https://github.com/collective-soundworks/soundworks-template-build/pull/1 There is also a test template project here if you need it: https://github.com/schlenger/soundworks-template/tree/typescript_support

Please check it carefully - I've tried to explain everything I did and everything I've found out so long. Right now it seems to work for JS and TypeScript, so I've created a pull request to merge it into the main project.

Let me know what you think of it.

b-ma commented 3 years ago

Ok thanks !

I'll check it, some of the parts are a bit confusing for me as I never used typescript, so I will have to dig a bit to understand more precisely what's going on there. But at first sight it looks like a quite simple solution

I let you know