Typescript definitions for UXP?

InDesign
,
1

I know it is possible to build a UXP plugin using Typescript, which I would like to do. Is there an existing @types project for InDesign and InDesign UXP? Is there another project other than @types that might have the definitions?

1 Like
2

I got ok-ish to good results with this file:

It’s a mix takes the UXP types by @thejustinwalsh (there are also other projects out there that have, some more updated than others, type definitions for the core UXP APIs) and the classic “Types for Adobe” project’s InDesign types for the host-app-specific APIs, removes all the declare keywords in it, and wraps it in a declare module ‘indesign’ {…}.

There’s also currently an active effort by Adobe to have official TypeScript definitions for at least the core UXP APIs, but I’ve had a few issues trying it a few days ago, so it might still take a few days/weeks for those to be usable “without intervention”.

PS: Note that those solutions aren’t super pretty or working perfectly, yet (so using them for strict type checking might cause issues). But it’s better than nothing at least :wink:

2 Likes
3

I appreciate the help, thank you

1 Like
4

Do you know if there’s any update on official Adobe typings for InDesign (or maybe somewhere to see progress)? I’m using this file you linked here, and it works, but it’d be nice to be backed by Adobe.

1 Like
5

Not to my knowledge (although I don’t work for Adobe anymore – maybe @pkrishna has some more up-to-date information, since I’m not sure who’s responsible for the InDesign end of things at the moment?).

Unfortunately, the way this works on Adobe’s end is that the InDesign APIs (everything in require('indesign')) is managed by the host app team (i.e., here, the InDesign team), while the core UXP APIs are managed by the UXP team. So the fact that UXP, by now, provides official types (which still leave lots of room for improvement with quite a lot of wrong and/or any types, but hey – at least we now have official types), and Photoshop’s UXP APIs have had well-working type definitions for a long time, we can only hope (but I don’t think it’s very likely to happen) that the InDesign team decides to commit resources to supporting TypeScript definitions for their APIs :thinking: .

1 Like
6

The InDesign scripting documentation is abysmal nowadays. Way back with ExtendScript Toolkit browsing the API wasn’t too bad (though ESTK was super buggy), but since then the only usable documentation has been third-party. Now that doesn’t seem to have been updated since InDesign 2022 either sadly…

https://www.indesignjs.de/extendscriptAPI/indesign-latest/#about.html

How difficult could it be for Adobe to generate similar up-to-date web documentation based on whatever internal format they have for this? And generate TypeScript definitions as well? The only official documentation right now has no categories and no cross-references making it very hard to browse.

1 Like
7

You won’t get any argument from me. However, while I agree that the things provided officially at the moment are (in terms of reference) unusable, I will say that:

(tl;dr: if we want to have things like TypeScript definitions and a proper API reference, they will have to come from the developer community)

Truthfully: very. Not due to technical challenges, but more so a mix of the amount of cross-team efforts this would take (there are >= 3 teams that would have to commit to work on this). Combined with what, in my opinion, is a complete and utter under-staffing and under-resourcing of desktop extensibility ever since Adobe Express / Web Extensibility is a thing. And to get three teams to have the resources to do something that isn’t deemed strategically important (like the web extensibility at the moment is) is next to impossible.

To be clear: I’m not saying this to claim that the platform is bad. It isn’t. I’m still a plugin developer after having worked on the platform (and, in fact, the InDesign UXP launch) myself during my time at Adobe. But: I wouldn’t hold my breath waiting for Adobe to provide a good API reference themselves. Which is sad, but it is what it is.

Even more so, unfortunately. For more reasons than I have the time to write here.

I realize that my response sounds very much like an old grumpy person :sweat_smile: . And perhaps I am – a little. But my reason for (while agreeing that this would be greatly beneficial to all of us) so bluntly rejecting these claims of “how difficult can it be” is that: Based on my experience (both as a plugin developer and former Adobe employee), as much as I regret to say this, these will probably never happen.

This isn’t to blame on any of my former co-workers – what they can achieve to help all of us with the limited resources they have assigned to them is incredible! But: this situation means that things that, from the outside, let us think “how difficult can it be” can be impossible to achieve (which is frustrating for both sides).

So where does this leave us? With the conclusion that if we want these things (which a lot of us do, I think), they will have to (continue to) come from us, the community. Back when UXP was entirely new (and only in Adobe XD), the developer community was extremely tight-knit, which helped with these sorts of things. This is somewhat more complicated with UXP in InDesign, as the dynamics in the developer community are far more complicated (devs coming from InDesign to UXP, UXP to InDesign, entirely new, etc.). The ExtendScript based extensibility, of course, had a lot of dev community resources (including, but not limited to, indesignjs.de.

What we have to do now is to find a way for this sort of community effort to be established in the “UXP meets InDesign” land. I very much hope (and like to think) that we will find this way.

Because, for better or for worse: I don’t see a way where these things will be provided by Adobe.

3 Likes