Add support for publishing in definitely-typed repository

[tato123]

Enhancement request

Overview

For projects that utilize typescript and npm, types can be associated to a project by downloading the library via npm and exposeing a typings key. The request is to create the necessary values and expose the library on npm as a published package

Changes required within repository

• Create a package.json
• Add "typings": "./types/index.d.ts" key/value

Additional owner / contributor changes

• publish changes to npm
• stretch goal: use a build system to publish changes upon merge to master

[tato123]

Included a pull request with the proposed changes #29

[pklaschka]

Alright – let's now discuss how we can go about publishing to npm here. @kerrishotts Any thoughts (the problem if I just publish it myself is that it would be difficult to get access rights for Adobe staff (since I don't have any paid npm account and therefore very limited "contributor management" features)?

[ashryanbeats]

Thanks for bringing this up. I've also added @dkstevekwak to the discussion here. We can learn from how Kerri is handling things for xdpm today.

To sum up what I've seen here and elsewhere, the issues we're trying to solve for are:

• Avoid having a single point of failure in the publishing workflow
• To the extent possible, automate the process

Is this accurate?

[tato123]

@ashryanbeats yes, your summary is accurate. It was a stretch goal, however it would simplify maintaining this project as a community lead library.

I should however have renamed this request. One thing I realized after I created this issue was that using definitelytyped would require the type definitions of this project to be moved over to the definitelytyped repository.

However, I do not think that is not necessary since major libraries like firebase and redux maintain their typings outside the definitelytyped repository.

[pklaschka]

@ashryanbeats Another thing is that since I'm currently basically the sole maintainer of the repo, we need to have some way of publishing it to npm with

1. me not being the only one able to publish it (which would happen if I just published it myself)
2. me being able to publish it (since – at least from what it looks like right now – I will for the near future be the person to make changes and always having to wait for someone on your side to review and publish it would only make things more complicated and increase work for both sides 😉 )

[pklaschka]

@ashryanbeats @kerrishotts Is there any update on this? I don't mean to pressure you, but "We can learn from how Kerri is handling things for xdpm today." was five days ago 😉

[pklaschka]

@kerrishotts @ashryanbeats @dkstevekwak Sorry to be tagging you all here, but is there any news about this? The today in

Thanks for bringing this up. I've also added @dkstevekwak to the discussion here. We can learn from how Kerri is handling things for xdpm today.

is more than a month ago 😉

[ericdrobinson]

I've some comments that I hope will be helpful to this discussion.

Communicating the Purpose of Typings

First, I would strongly suggest that you be careful as to how you message the purpose of these typings. I bring this up because the first sentence of this issue starts with:

For projects that utilize typescript and npm

Type Declaration Files (aka "typings") are not just for TypeScript. They power immensely powerful features for pure JavaScript when used in compatible editors. With the very typings you guys have in these documents you can help your pure-JavaScript developers as well! To that end, I would suggest that you simplify that statement to simply read:

For projects that utilize npm

I'm not trying to suggest that you guys update this Issue specifically, but rather that you take a broader view of the importance and impact that these files may have for your XD (and, eventually, the greater UXP) developers.

Case in point: I am not an XD developer; I've never touched the program. However, by simply downloading this repository and creating a test.js file, I'm able to begin writing pure JavaScript in Visual Studio Code with IntelliSense-powered autocomplete and inline documentation. See:

Versioning the Typings

Second, as I've not seen any [public] conversation on how to structure these typings with respect to host application version changes, I would like to suggest that you take a page out of the NodeJS type declaration versioning. Perhaps this was the plan all along, as it's the approach suggested by DefinitelyTyped, but I think it's worth bringing up for the avoidance of doubt.

This means that you would end up supporting multiple "versions" of typings. It also means that you could guarantee that users with, say, scripts targeting XD 14 specifically could set their type dependencies to something like @types/adobe-xd-uxp@14 and guarantee that an npm update wouldn't suddenly poison their ambient type declarations with APIs that don't actually exist for their target platform yet.

Currently, APIs in this repository are documented with notes reading something like:

Since: XD 14

This is excellent information, but it isn't functional. Properly versioning the types allows users to code in an environment that only suggests APIs available to their specified target.

Separating UXP from XD

My understanding is that UXP is the eventual successor to CEP and will be adopted by other host applications over time. To support this paradigm, I would strongly suggest that you treat the uxp typings as their own package that the "adobe-xd-uxp" typings reference. With the versioning support outlined above, you could ensure that your @types/adobe-xd-uxp@15 has a dependency on @types/adobe-uxp@1 while, say, @types/adobe-xd-uxp@20 has a dependency on @types/adobe-uxp@4.

Other host applications could then also benefit from the core uxp type declarations by referencing them as needed.

---

Perhaps everything I've typed in this comment matches the implicit approach that was already planned... if so, cool! If not, I only hope that this comment starts a constructive discussion on the topics raised.

[pklaschka]

@ericdrobinson

I've some comments that I hope will be helpful to this discussion.

Communicating the Purpose of Typings

First, I would strongly suggest that you be careful as to how you message the purpose of these typings. I bring this up because the first sentence of this issue starts with:

For projects that utilize typescript and npm

Type Declaration Files (aka "typings") are not just for TypeScript. They power immensely powerful features for pure JavaScript when used in compatible editors. With the very typings you guys have in these documents you can help your pure-JavaScript developers as well! To that end, I would suggest that you simplify that statement to simply read:

For projects that utilize npm

I'm not trying to suggest that you guys update this Issue specifically, but rather that you take a broader view of the importance and impact that these files may have for your XD (and, eventually, the greater UXP) developers.

Case in point: I am not an XD developer; I've never touched the program. However, by simply downloading this repository and creating a test.js file, I'm able to begin writing pure JavaScript in Visual Studio Code with IntelliSense-powered autocomplete and inline documentation. See:

Sounds great. In fact, I had initially developed the typings to only get used for autocompletion – the fact that they work for TypeScript as well were an added bonus where we had basically only afterwards discovered how they can get used for TypeScript 😉

Versioning the Typings

Second, as I've not seen any [public] conversation on how to structure these typings with respect to host application version changes, I would like to suggest that you take a page out of the NodeJS type declaration versioning. Perhaps this was the plan all along, as it's the approach suggested by DefinitelyTyped, but I think it's worth bringing up for the avoidance of doubt.

This means that you would end up supporting multiple "versions" of typings. It also means that you could guarantee that users with, say, scripts targeting XD 14 specifically could set their type dependencies to something like @types/adobe-xd-uxp@14 and guarantee that an npm update wouldn't suddenly poison their ambient type declarations with APIs that don't actually exist for their target platform yet.

I agree. Since this is also the versioning system I've used for tags or releases here on GitHub (v14.0 for XD 14, v15.0 and v15.1 as "revisions" of XD 15, cf. https://github.com/AdobeXD/typings/releases), we can just continue to use that system.

Currently, APIs in this repository are documented with notes reading something like:

Since: XD 14

This is excellent information, but it isn't functional. Properly versioning the types allows users to code in an environment that only suggests APIs available to their specified target.

Since I want to reflect the API info in the docs comments, this is something which – as long as I basically maintain the repo – will probably remain. It is, however, not meant as a replacement to using the typings at a specific version, but used to note any changes. With API-changes on XD's side, this info isn't meant as a functional "warning", but just as a reflection of the API docs. I may, for example, check the lowest compatible version without having to look up the API docs website for every function that way.

Separating UXP from XD

My understanding is that UXP is the eventual successor to CEP and will be adopted by other host applications over time. To support this paradigm, I would strongly suggest that you treat the uxp typings as their own package that the "adobe-xd-uxp" typings reference. With the versioning support outlined above, you could ensure that your @types/adobe-xd-uxp@15 has a dependency on @types/adobe-uxp@1 while, say, @types/adobe-xd-uxp@20 has a dependency on @types/adobe-uxp@4.

Other host applications could then also benefit from the core uxp type declarations by referencing them as needed.

I think that that's a great idea. However, I think that this will only become relevant when other host applications use uxp. As long as there aren't any other host apps accessible to me (I'm saying it that way since I can – of course – not exclude the possibility that some other app already has a prerelease program regarding UXP extensibility which I'm unaware of), I think it's easier to keep this managed in here.

Perhaps everything I've typed in this comment matches the implicit approach that was already planned... if so, cool! If not, I only hope that this comment starts a constructive discussion on the topics raised.

From the looks of it, I mostly agree with you (and while I'm not working at Adobe, I'm basically currently maintaining this repo, so chances are good things we agree on might get done that way, unless anyone from Adobe says something against it 🙂 ). Besides that, constructive ideas, criticism and discussions are always welcome here, so thank you for your suggestions 👍

[ericdrobinson]

@pklaschka

It is, however, not meant as a replacement to using the typings at a specific version, but used to note any changes. With API-changes on XD's side, this info isn't meant as a functional "warning", but just as a reflection of the API docs. I may, for example, check the lowest compatible version without having to look up the API docs website for every function that way.

Ahh, apologies: I didn't mean to imply that those "Since: notations" intended to serve a functional purpose as they exist in the typings today. I simply meant to point out to those less-familiar with the whole typings paradigm that the versioning is functional, whereas those comments are informational. Both is definitely best!

That said, I might suggest that such comments be moved to the bottom of the documentation block. One could easily argue that seeing the description of the API in question is more valuable than seeing what version the API was added to...

I think that that's a great idea. However, I think that this will only become relevant when other host applications use uxp. As long as there aren't any other host apps accessible to me (I'm saying it that way since I can – of course – not exclude the possibility that some other app already has a prerelease program regarding UXP extensibility which I'm unaware of), I think it's easier to keep this managed in here.

Entirely reasonable. My only desire in raising the concern was to ensure that it had been considered as part of the process. Only Adobe devs know the UXP status for other host applications, so this is basically a "keep this in mind" heads-up for them.

[pklaschka]

@ericdrobinson

@pklaschka

It is, however, not meant as a replacement to using the typings at a specific version, but used to note any changes. With API-changes on XD's side, this info isn't meant as a functional "warning", but just as a reflection of the API docs. I may, for example, check the lowest compatible version without having to look up the API docs website for every function that way.

Ahh, apologies: I didn't mean to imply that those "Since: notations" intended to serve a functional purpose as they exist in the typings today. I simply meant to point out to those less-familiar with the whole typings paradigm that the versioning is functional, whereas those comments are informational. Both is definitely best!

That said, I might suggest that such comments be moved to the bottom of the documentation block. One could easily argue that seeing the description of the API in question is more valuable than seeing what version the API was added to...

Ah, alright. that sounds reasonable (looks like we now agree on all of your points 🎉) – I'll see if I can change the order in those doc comments in the next "bigger" update of the typings.

I think that that's a great idea. However, I think that this will only become relevant when other host applications use uxp. As long as there aren't any other host apps accessible to me (I'm saying it that way since I can – of course – not exclude the possibility that some other app already has a prerelease program regarding UXP extensibility which I'm unaware of), I think it's easier to keep this managed in here.

Entirely reasonable. My only desire in raising the concern was to ensure that it had been considered as part of the process. Only Adobe devs know the UXP status for other host applications, so this is basically a "keep this in mind" heads-up for them.

👍

[pklaschka]

Upon request, I just summarize what this issue is about / what's currently waiting for help by folks at Adobe:

We need some way to publish the typings to npm in a way that I can push updates (to avoid always waiting for someone having time to look into it when I find the time to update the typings) but where I don't have "exclusive" access to publishing (it is, after all, an "official" Adobe XD thing and not my personal project anymore).

One way could be to integrate this with some kind of CI system that automatically pushes the Master branch to npm, this would, however, require set up by Adobe (to ensure that administrative rights remain with Adobe so that the npm package can also be an "official" thing.

[ashryanbeats]

Hi all, apologies for our extended absence in this conversation and thanks to Pablo for pushing us to respond.

1. To be transparent, the team doesn’t have the bandwidth to get deeply involved at the moment (unfortunately) as we're working on hiring
2. What I will do is reach out to our open source team at Adobe to see if publishing by non-Adobe employees is even possible, given the 2FA setup on Adobe's npm org

[pklaschka]

@ashryanbeats Thank you very much for your answer.

In this case, for now, we're gonna take the road of insalling the repo directly from GitHub (if needed, via npm: npm install AdobeXD/typings) and remain open for a different solution, should one arise.

As soon as the documentation for the typings is updated in this reagard, though, I'll close this issue as it, then, is "as resolved" as we're going to get without further ideas.

[ericdrobinson]

I'll close this issue as it, then, is "as resolved" as we're going to get without further ideas.

I would highly recommend not doing this. Rather, I would recommend adding the TBD / Future label to it.

If this Issue was titled "Add support for installing with NPM", then I'd say 👍 as the documentation adjustment you describe would resolve that. However, the core issue here is one of publishing to the ecosystem-standard type repository. If the answer is "can't do this yet", then it should not be marked as "Resolved". (This as opposed to an answer of "We will never do this": had this been @ashryanbeats's response, then resolving as "By Design" would be appropriate.)

You might also consider adding a label to the system that says something like "Adobe Required" or "Non-Community" or something and classify this task as such. Regardless, I would remove the "Help Wanted" label as community can't really do anything with it at this point.

This will also help people looking for official declarations in Definitely Typed from opening a duplicate issue after a cursory [read: "open" issues only] search.

Make sense?

[pklaschka]

@ericdrobinson I'd actually close it especially because of the scope of the issue. Support for publishing is now achieved (since it is possible to install the types via npm and the actually described scope doesn't, as per the author's request, strictly include adding it to Definitely Typed; This, to my knowledge, also wouldn't be possible as the guidelines of Definitely Typed aren't compatible with the structure of these declarations, or a structure necessary for Adobe XD: Globals, multiple ambient modules etc.). See this comment by the issue's author, for reference:

I should however have renamed this request. One thing I realized after I created this issue was that using definitelytyped would require the type definitions of this project to be moved over to the definitelytyped repository.

However, I do not think that is not necessary since major libraries like firebase and redux maintain their typings outside the definitelytyped repository.

Publishing to the npm registry actually is another issue, and I'd therefore suggest opening another issue for it. We have the support and as soon as it is documented, a solution for comfortably installing the types via npm.

The only remaining task in the scope of what's been asked for is publishing to the npm registry, and I don't believe that that's a real part of Adding support for publishing ....

Truthfully, I don't really care if this issue remains open or not, but as far as I'm concerned, the content of the issue is resolved, i.e., adding support for publishing [to npm, in one way or another]. I don't actually require help from Adobe for adding support, I require it for (a new issue:) publishing to npm...

[ericdrobinson]

Support for publishing is now achieved (since it is possible to install the types via npm and the actually described scope doesn't, as per the author's request, strictly include adding it to Definitely Typed;

If that's the case, then definitely change the title before closing this. Much of my initial commentary on this issue was with the assumption that the goal was to add these types to the @types npm namespace (organization).

Part of the point here is that the following is a hack:

npm install --save-dev @types/adobe-xd@git://github.com/AdobeXD/typings.git

The reason I suggested the @types organization identifier was entirely due to the fact that I assumed the goal was to eventually move these to Definitely Typed - because of this very issue. The assumption is that one day the "@git..." portion will simply go away and people will update from the official, standard type declarations source. If you have decided to forego Definitely Typed integration, then perhaps it makes sense to change that to be something more npm-global (e.g. adobe-xd-types, including possible instructions on how to update the typeRoots field of the config files, if necessary - haven't tested).

See this comment by the issue's author, for reference:

...
However, I do not think that is not necessary since major libraries like firebase and redux maintain their typings outside the definitelytyped repository.

This is wrong: both Firebase and Redux include their types in their base npm packages directly. This is always an option for pure JavaScript/TypeScript libraries.

A more apt comparison for the ambient-style of these declarations is NodeJS. Those declarations DO show up on npm. NodeJS also features the following:

• Globals
• Ambient Modules

NodeJS was very much an inspiration for the UXP environment Adobe has been using XD to work out. I can't currently see where there would be a technical problem with eventually adding type declarations to Definitely Typed here.

This, to my knowledge, also wouldn't be possible as the guidelines of Definitely Typed aren't compatible with the structure of these declarations, or a structure necessary for Adobe XD: Globals, multiple ambient modules etc.).

Where do you see these restrictions? Perhaps there's something I'm not aware of...

The only remaining task in the scope of what's been asked for is publishing to the npm registry, and I don't believe that that's a real part of Adding support for publishing ....

Truthfully, I don't really care if this issue remains open or not, but as far as I'm concerned, the content of the issue is resolved, i.e., adding support for publishing [to npm, in one way or another]. I don't actually require help from Adobe for adding support, I require it for (a new issue:) publishing to npm...

If that's the case, then definitely change the title of this issue to something like "Add support for installing types from npm". That removes "definitely-typed" from the title and disambiguates it a bit.

I, for one, have been operating under the assumption that this issue encapsulates officially adding the types to Definitely Typed. I'm happy to move the discussion to a separate issue and possibly link back to this one for context :)

That issue can also potentially handle the question of how to handle UXP APIs vs application-specific ones (I understand this is likely to happen this year at some point).

[ashryanbeats]

Hi all, our colleagues in the open source office let me know that allowing non-Adobe employees publish directly on our behalf to npm isn't possible (and I'm sure we all must have expected this to be the case 😄 , but it was worth getting a definitive answer).

If we do get bandwidth to address this in the future, they mentioned that setting up CI/CD could be a viable option:
https://sergiodxa.com/articles/github-actions-npm-publish/

I'll leave it to your collective judgement to decide how to triage this GitHub issue for the future. For now, I just wanted to share the latest info along with hopes that we can be more helpful in the future.

[ericdrobinson]

If we do get bandwidth to address this in the future, they mentioned that setting up CI/CD could be a viable option

Is the suggestion here that you guys would set up CI/CD to submit to NPM while continuing to accept PRs from the community?

If so, that would certainly bypass the "community pushes under Adobe's name" issue.

That said, it might also be possible to set up CI/CD such that it automatically creates a PR into the DefinitelyTyped repo to get officially added to the @types namespace.

[macdonst]

Hi all, I'm Simon MacDonald and part of Adobe's Open Source Office and @ashryanbeats has brought me on to help. I've got admin access on this org now so I can setup a github action that will publish the package to npm using our adobe-admin account so everything is nice and official.

Here are the currently available publish to npm github actions. Can folks take a look over them so we can have a dialog about what works best for your use case?

https://github.com/marketplace?utf8=%E2%9C%93&type=actions&query=npm+publish

Then we can work together to make sure this gets setup and into production. Plus if it goes well we can look at automatically sending a PR to the @types namespace as well.

cc: @ericdrobinson @pklaschka

[macdonst]

Also, I'd like to change the package name from @adobexd/typings to @adobe/typings as there is no Adobe XD org on npm. Make sense?

[ericdrobinson]

@macdonst I would highly recommend against publishing this repo to NPM directly and instead follow the instructions to publish directly to the @types namespace. Getting these into two locations in NPM can only lead to confusion and unnecessary maintenance costs.

I'd like to change the package name from @adobexd/typings to @adobe/typings as there is no Adobe XD org on npm.

I'm not entirely sure what you're suggesting here. The AdobeXD GitHub organization could easily contribute to the NPM @adobe namespace...

That said, calling such a package @adobe/typings would be an extremely unfortunate move. Here's some context:

1. These Type Declarations are effectively "header files for JavaScript". They allow your tools understand the context of an environment without actually being in that environment.
2. The Type Declarations in this repository are specifically for Adobe XD.
3. Soon, other applications will also gain Type Declarations.
4. These Type Declarations are made up of TWO related contexts:
   1. UXP general APIs: APIs that all UXP applications will share in common.
   2. Adobe XD APIs: APIs that only exist in the Adobe XD application. These are an extension to the UXP APIs.

What this means is that eventually you will be looking at having multiple related type declaration packages. These will look something like:

• @types/adobe-uxp-core
  • @types/adobe-uxp-xd
  • @types/adobe-uxp-photoshop
  • @types/adobe-uxp-illustrator
  • @types/adobe-uxp-premierepro

The reason the applications are represented below the core types is that the core would presumably be shared across applications (it would be a shared dependency that each application independently extends).

I should also point out that the Type Declarations would be versioned as well. Each new release of an application has a high likelihood of adjusting the supported API in some way. This means that you might run npm install @types/adobe-uxp-xd@24 to get the type declarations compatible with Adobe XD v24.

The process for publishing to the definitely-typed repository will involve a number of steps and I don't have any specific recommendations, unfortunately. I will wrap up with a list of factors to consider for this:

1. Breaking out UXP Core from XD-specific APIs (rumor has it a second UXP app is coming soon).
2. Handling host application version updates (which include API updates/changes).
3. Forking and issuing PRs to the DefinitelyTyped repo.

Make sense?

[macdonst]

@ericdrobinson Hmm…I thought it was settled that the community wanted this repo published as an npm package. I'd love to hear from everyone whether this package should:

1. be published to npm
2. PR to the DefinitelyTyped repo
3. both 1 and 2

The reason I suggested changing the name from @adobexd/typings to @adobe/typings was because publishing to npm would fail the way it is currently setup as there is no adobexd org on npm. We can punt that decision until will have clarity on my above question.

[pklaschka]

I don't care too much about which way we go.

However, since XD updates are pretty frequent and I already have trouble keeping up with them as it is, adding the bureaucracy of managing PRs for the repo over at @types doesn't exactly sound appealing to me.

I still have exams this week, but hopefully, I'll find the time to research how feasible publishing to @types might be and will "report back."

On the other hand, from what I gathered from @ashryanbeats comment, as (no surprise there) publishing by non-employees isn't an option. As pushing to the master branch is the same as publishing to npm when establishing CI/CD, I presumably wouldn't be able to maintain the repo any longer. That, then, means it's at least just as much effort to release a new version in such a system. For reference: For now, I'm allowed to maintain the repo. I usually open PRs with updates and request review where "no review within a reasonable amount of time" gets considered as approval (as otherwise, the typings would be out-of-date more often than up-to-date). @macdonst You probably can't give me other options there?

No matter which option we choose, we'll need help from (and significant aspects will have to get done by) Adobe, though, since this, of course, officially belongs to Adobe (cf. the repo's License). Therefore, I'd assume that I'm rightfully not just allowed to "just submit a PR for this" to @types...

[ericdrobinson]

Hmm…I thought it was settled that the community wanted this repo published as an npm package.

@macdonst There was discussion about whether or not to publish the repo as a raw npm package or contribute to Definitely Typed (the @types namespace). But the conversation somewhat trailed off. The arguments against Definitely Typed were basically debunked in the last comment I posted in that discussion here.

Of the two options, @types is definitely preferable for users as it is effectively "standards-compliant".

In response to your three options, the third would simply be a nightmare for everyone so it's out. I cannot urge strongly enough that we agree that "Type declarations should go on Definitely Typed". Of your list of three options, it's number 2.

The reason I suggested changing the name from @adobexd/typings to @adobe/typings was because publishing to npm would fail the way it is currently setup as there is no adobexd org on npm.

I think I may be confused by your description of this as "changing the name". If you simply meant "we'll map this repo to @adobe/typings because, well, there is no @adobe namespace", then I apologize for misunderstanding.

That said, adding this repo as typings under @adobe is 110% the wrong choice. This repository's name ("typings") is currently shorthand for "Type Declarations for Adobe XD". That last part is encoded in the fact that the repo lives under the AdobeXD GitHub organization. You can't move it to npm 1:1 (without changing the name). That was part of the reason why I suggested mapping the contents of this repo to something like adobe-uxp-xd as it explicitly says "these are the UXP API declarations for Adobe's XD application." Ambiguity gone.

That said, I think this conversation may be a bit premature. Pushing these to Definitely Typed (or, if those in charge decide they'd rather a different path, then NPM in general) should probably wait until a few more applications are gearing up for release with their own typings. I've heard that there is a drive to autogenerate the API type declarations at some point (which would free you up, @pklaschka!), but that there's no timeframe for it yet. Perhaps waiting until more is known from the development team(s) would be prudent here.

I would like to summon @kerrishotts for further comment! :D

[langri-sha]

I'm using Flow and it would be really nice if there were published types so we can convert these in a single step 👍. Using this run script from the repo clone for the time being.

diff --git a/package.json b/package.json
index 5af1cd9..44c2127 100644
--- a/package.json
+++ b/package.json
@@ -42,5 +42,8 @@
       "email": "fontanezj1@gmail.com",
       "url": "https://github.com/tato123"
     }
-  ]
+  ],
+  "scripts": {
+    "flowgen": "find types -type f -name '*.d.ts' -exec sh -c 'npx flowgen $0 --add-flow-header --interface-records --flow-typed-format flow/$(echo $0 | sed 's/d.ts/.js/g')' {} \\;"
+  }
 }

[ericdrobinson]

From speaking with @baaygun (an Adobe engineer) on a related topic, it sounds as though Adobe does have designs on maintaining type declarations on NPM. No word on when this is coming but there is hope that this will become an official thing. I'd be willing to bet that it will pick up steam as other Adobe host applications gain their own UXP integrations...

[hansottowirtz]

Does anyone know of available typings for other Adobe products than XD? If there's any ongoing effort I'm willing to help out.

[pklaschka]

@hansottowirtz For other products using UXP (i.e., at the moment, just Photoshop), I believe Adobe is planning to publish those types themselves (this, right here, is "just" a community-driven manual effort to create those types, after all).

For other extensibility systems (like CEP, etc.), other answers might apply. For instance, a quick search for CEP types resulted in the following results:

• https://github.com/bbb999/Types-for-Adobe
• https://github.com/Adobe-CEP/Samples/tree/master/TypeScript/typings

All in all, I guess it really depends on the platform/software/...

[hansottowirtz]

I spent the day building a crawler for the Adobe documentation, which generates Typescript typings: https://github.com/hansottowirtz/adobe-uxp-types-crawler. I'm pretty sure that there will be some inconsistencies because of incomplete documentation but it seems to work for now. There are only types for the photoshop module so people can use the types in this repository for the uxp module.

tl;dr You can now do npm i -D adobe-uxp-types-photoshop for Photoshop types.