D2 App Platform and Typescript

Hi there,

I have seen a mention of this question in a thread with no answers, so I thought I would make it a full topic. I have an app developed using the app platform, however when trying to migrate this over to typescript I am getting a number of errors relating to the d2 modules and project structure, I was wondering if there are any plans to document how to use typescript with the app platform? As quite a few people have been developing apps for DHIS2 in typescript without the app platform, it seems like this could be a cause for people to not adopt the platform until it’s supported.

Keen to hear other peoples thoughts too.

Many thanks for your time,

1 Like

@plinnegan can you share the specific errors you’re seeing?

There is support for compiling typescript in the platform (we use it for the app-runtime library) but we do not have official support for typescript applications and so that isn’t well-tested. I imagine it should work, it likely just requires some customization of the typescript config and type stubbing. If this is something people are interested in, perhaps typescript support could be added to the platform and/or a HOWTO guide added to developers.dhis2.org by you or others from the community?


Thanks for the quick feedback @austin! I will try and setup a minimal example and get back to you this week!


We’ve still not migrated to the App platform as we want it to mature a little bit more but we will definetely as soon as the PWA experience is stablished.

However I’ve been trying it out and checking what does it offer or not. TypeScript is a must on our needs as it’s our main language right now.

I can say that it “just works” with the app platform as-is just by adding your tsconfig, but you will lack type checking on a typical yarn start. I ended up adding typescript as a dev dependency and with concurrently running tsc on a watch mode.

You can check out the skeleton I built at: GitHub - SferaDev/dhis2-app-skeleton

However only the app runtime is actually written in TS so you will lack type definitions for most stuff like UI components and you will need to write your own .d.ts type definition overrides if you want them typed.

Disclaimer: The skeleton there is just an initial proof of concept we did for investigation purposes, it has not been used for any app yet but should be useful to check the infra set-up (eslint and TS).

@austin I’m writing a simple Form in TS right now and auto generating the type definitions from the prop types and adjusting them when needed for the components of dhis2/ui that I need.

What would make more sense: a DefinitelyTyped repo, contributions to the official repo in an index.d.ts or per component d.ts files? (The answer really depends on how much the core team is willing to maintain or support these definitions when they’re there, ie. community maintained (either in DT or UI) vs officially maintained).

I believe at least it makes sense having the type definitions split in each of the monorepos core, widgets, etc… And join them in the main ui package.

Not saying that I have anything ready yet but is something I will have soon on the app side and it would make sense to contribute it back.

So far I have Tabs, Tab, InputField, Transfer, SingleSelect, MultiSelect, some more, all their variants for FF and a couple of form validators.

Hi @SferaDev - this is awesome, thanks for looking into it! I’m not sure we have bandwidth to maintain types alongside the JS code (we would convert to TS in that case) so maybe DT is the way to go. This gets a bit more complicated with recent versions of ui because there are now separate packages for each component, which would need to be re-exported from the main ui and other collection packages.

cc @varl

Hi @austin and @varl, I’ve begun working on this. Since the task is enormous, I will follow this approach:

  • Add definitions for @dhis2/ui-constants [DONE]
  • Add definitions for @dhis2/ui-icons [IN REVIEW]
  • Build infrastructure for @dhis2/ui with re-exports and components with auto generated props [IN PROGRESS]
  • Polish the type definitions with function parameters and return types [FUTURE]

Not sure if on your side you want to be part of the process, maybe as DT co-owners (PR reviewers).