H5P Group should formally support Typescript for lib development

If H5P published and maintained a types library along with the framework itself and illustrated and encouraged the use of TypeScript in the documentation (TS library project templates would also be terrific), it would make the framework more readily discoverable and generally encourage more rigor among the H5P developer community; I believe devs would also find it a better development experience overall and that it would lead to better quality community code over time, all of which would help drive greater adoption. Having the H5P Group itself publish and oversee their maintenance would give developers greater confidence that they could lean on those libraries in the long term.

At the end of the day, the Group _does_ dictate what language is used: ECMAScript. TypeScript's still the dominant strongly-ish "typed" language in that ecosystem, with a very low cost of entry. Making it a first-class citizen in the _H5P_ ecosystem just makes sense to me.

I'd argue that most mainstream, significant open source JavaScript projects are now maintaining their types libraries as part of core. I think the H5P Group needs to adopt one for the same reason h5p-cli, h5p-php-library, and a host of other projects live in the organization's namespace. It implies a contract with their community: this is an important element of our platform's development ecosystem, and we're going to make sure it stays aligned with the development of the standard.

I'm not arguing that they're preventing me from doing anything. Nowhere did I make that claim. I'm just arguing that adopting a types library into core would show a commitment to broadening the appeal (and thus the long life) of the platform and ensuring it's given as much running room to grow as possible.

I'm trying to build libraries and content types that have legs and staying power for my organization and the educators that depend on us, and I want to make life as easy on whoever comes behind me and has to maintain what I've written as I can. For something as simple yet critical (in my world) as a types library (types are kinda' central to Typescript development, and are littered pretty liberally throughout my code), I'd prefer not to rely on a community project that largely depends on a single individual for its continuance; there's a lot of risk of great future pain implicit in doing so.

I'm admittedly biased, but I don't think it's an unreasonable suggestion. You clearly do. We can agree to disagree; that's perfectly fine.

(The comment re: ECMAScript was tongue firmly in cheek, by the way; not like they had a choice! ;-)

I think we're talking past each other, otacke.

I'm not saying the Group has to actually build the thing -- please go back and read my original post. But as the organization purportedly steering the project, yes, the Group has some responsibility, here, for structuring things to ensure the larger project's continued relevancy and vitality. One of those responsibilities to my mind -- and perhaps their chief responsibility --  is nurturing a healthy development ecosystem. My contention, humbly, is that Typescript language support should be considered a core element of that ecosystem.

A types libary is a simple -- but very critical -- requirement for that developer base. Whether Group members actually write the code or merely give their blessing and guidance to a community effort to do so in the Group's name is all the same to me. There's no good reason to have a bunch of little, uncoordinated community efforts sitting out there in the registry, in my opinion.

That's how the best open source projects work, imho: the governing body identifies important work to be done, asks for community members who are interested to volunteer to tackle the work, and helps steer their efforts. There are already community members clearly interested. They wouldn't even have to start from scratch, thanks to Sindre et al.

I'm very happy to contribute to that effort. But, yes, if they are going to do something in the name of the entire community, the Group has to bless and help steer it. 

I'd be happy to make the suggestion via Github issue (I'm just not sure what project to do so in, since it seems all the core JS front end code's maintained as part of the two PHP lib projects) or another channel.