Hi @Convly and thanks a lot for the very detailed response!
Let me give you some context as to why I’m still a bit sceptical about Strapi+TypeScript:
I was working as a frontend engineer at my last company. I was part of the team that developed an Angular driven frontend application. TypeScript was famously developed together with Angular IIRC (or at least they were enhanced by and benefited from each other in the early days) so these go very well together. In that frontend application (and in every other clean Angular application), everything is typed. Actually, even the recommended typescript-eslint config warns you that “The any type in TypeScript is a dangerous “escape hatch” from the type system.”.
Now, obviously Strapi has a completely different background, foundation and business case than Angular.
And when Strapi v4 was released, there was still not TypeScript support initially. Now it’s 2023 and TS support is still very basic.
Also the code can significantly document itself. I’m pretty active in the forum and on discord and the amount of questions that are based on the fact that the state of variables and objects are unclear, or which functions are available at which point, are mindblowing.
Now let my try to respond to some of the points your mentioned
to work with the very generic data structures we’re used to in Strapi
That’s true, there are some very generic data structures. Also I think this “autodiscover” principle (if a file exists in a certain folder and has a certain name, it has a certain meaning) is a bit weird. Without knowing exactly a possible alternative solution, I feel like Generics and Decorators (ES, TS, ng) could be very helpful.
Also the global almighty
strapi object feels problematic right now. There are properties that are not documented, but even the documented stuff behaves unpredictable. There is no guarantee that
strapi.service('api::restaurant.restaurant') returns something and that something is the restaurant service. Let alone my IDE can suggest to me which functions the restaurant service has. It feels pretty 2010 and earlier when this exact problem existed in JS driven frontends.
As a small reminder/context, 4.3 included TypeScript support
You know what, actually I might have misunderstood and overestimated what exactly this means. Thanks to your clarification I know now, but for the reasons mentioned above I’m not sure what real value it brings at this state.
Well, this is actually in the scope of the 4.3 release
I’m curious about what you would have imagined as an alternative workflow. (Also keep in mind that plugins are still independent Strapi pieces)
When I add a local plugin to my TypeScript driven Strapi project, I have to have a second terminal open and run
npm run develop in there so that my TS plugin gets transpiled to JS. Because my Strapi project, despite being written in TS, only recognized the transpiled plugin in the dist folder. This feels awkward and has repeatedly led to confusion by discord users.
I haven’t tried the following yet, but I wonder how this would work when I want to publish a plugin written in TS on npm or the Strapi marketplace. It has to be compatible with JS Strapi projects. I guess I’d have to publish only the dist folder then, and maybe some types, but not the actual TS implementation.
We’re exploring a lot of options and ideas for V5
I’m very curious about the future of Strapi, because as much as I hated it in the beginning for all its unpredictabilities (sorry I’m just being honest), I started to really like it in the recent weeks. Because at the very foundation, I find it very easy to quickly create some schemas and have a content API with little to no implementation. But then again, I’m not sure about the scalability with the current architecture.
We’re going to start crafting RFCs once we start the TypeScript work, I think it’ll be an awesome place to collect feedback and ideas. Stay tuned!
Count me in to contribute if I can and may
Have a nice day!
And have a nice day yourself!