# types-for-adobe: TypeScript definitions for scripting the Creative Cloud apps

> types-for-adobe publishes TypeScript type definitions for the ExtendScript APIs of Photoshop, Illustrator, After Effects, Premiere, Animate, Audition, InDesign and ScriptUI, one set per host application version, so a script can be written against the exact release it targets.

**docsforadobe/Types-for-Adobe** — TypeScript types for Adobe: AfterEffects, Animate, Audition, Illustrator, InDesign, Photoshop, Premiere, ScriptUI.

- Repository: https://github.com/docsforadobe/Types-for-Adobe
- Stars: 647 · Forks: 139
- Language: Shell
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/docsforadobe-types-for-adobe

## Typedef files, one directory per Adobe product

types-for-adobe is a repository of typedef files for various Adobe Creative Cloud products, and the package manifest shows the layout. The published files list is one directory per product, AfterEffects, Animate, Audition, InDesign, Illustrator, Photoshop and Premiere, plus a shared directory. The repository root carries the same directories and adds MediaEncoder, which is not in the published package, along with a _bin directory and a _resources directory. The package is published to npm as types-for-adobe at version 7.2.6, and the repository description lists the coverage as AfterEffects, Animate, Audition, Illustrator, InDesign, Photoshop, Premiere and ScriptUI. The whole thing is MIT licensed. What you are installing is type information, not a runtime library: there is no code to call, only declarations that tell the compiler what an Adobe host object looks like, which is the point, because ExtendScript has no type system of its own.

## The first script, and the tsconfig that makes it work

The README walks through creating a first script for Adobe Illustrator, and the sequence is short enough to follow exactly.

```bash
# create new folder
mkdir my-script
cd my-script

# install types-for-adobe
npm init -y
npm i types-for-adobe

# create tsconfig.json
printf '{"compilerOptions":{"module":"none","noLib":true}}' > tsconfig.json

# create index.ts and change reference types to Adobe product you're targeting
printf '/// <reference types="types-for-adobe/Illustrator/2015.3"/>\nalert(String(app));\n' > index.ts

# compile typescript files
tsc
```

Two details in there carry the design. The compiler options are module none and noLib true, because ExtendScript is not Node and has no module system or standard library, so the TypeScript standard library would be wrong. And the reference path includes both the product and the version, types-for-adobe/Illustrator/2015.3, which is how the version pinning works. After compiling you run the output from the host application, in this case by opening index.js through File, Scripts, Other Script in Illustrator.

## Where the definitions come from, and the accuracy caveat

The FAQ answers the question you should ask about any generated type definitions, which is where they came from. Everything in the project was generated through one of two methods. The first is an extendscript-xml-to-typescript converter tool that converts scripting dictionaries to typedef format, with the note that this only works for a few select apps and has been found to generate incorrect data in some cases. The second is by hand, referencing Adobe's official release announcements and developer exploration through the API. So the definitions are a mix of machine-generated and hand-checked entries, and the generated part has known failure modes. That is worth knowing before you build an error-handling strategy on top of the types, since a wrong field name in a definition compiles cleanly and then fails at runtime inside someone's Adobe session.

## Versioning per host app is the point, not an inconvenience

The FAQ has a section on why there are different versions of docs per version of each host app, and the reasoning is the strongest argument in the README. The repository aims to maintain a history of typedefs for each given version of each host app, so that if you are developing a tool aimed at Adobe After Effects v18.0 you can have your tool specifically use those typedefs and know that you are not using features introduced in a later version. The rationale differs by audience. For public commercial tools, the user base of some host apps is spread across multiple versions, and targeting a slightly older version ensures wider adoption than focusing solely on the latest. For internal proprietary tools, some companies mandate that all artists use a specific older version, and separate definitions for that version allow for that targeting. The advice on which to use is correspondingly practical: pick the newest if you can assume a specific version or newer, and pick the older one if you need a feature from a specific point and then tell your users that is the minimum supported version.

## Missing versions are usually a no-change release

The FAQ explains why some release versions are missing, and the two answers are both mundane. Either there have not been any API changes for that given version, or nobody has taken the time to add typedefs for that version, with an invitation to open a pull request. The first answer is the common one and it is worth internalising, because a missing version directory is not necessarily a gap in coverage. The second answer is a genuine gap, and the fix is contribution. The repository carries a.prettierrc, a package-lock.json, a yarn-error.log at the root and a single script, test, which runs _bin/test.sh, so there is a test harness that runs as part of the package's own script definition. The publish section documents the release process: log in with npm login, confirm the account has publish access to the package, bump the version in package.json, run npm publish, and push the commit with the new version to GitHub.

## Conclusion

types-for-adobe fits a developer writing ExtendScript panels for Photoshop or Illustrator who wants type checking and editor completion instead of a wall of untyped host objects. It does not fit a team that writes once and expects to run on any host version, because the whole design is version-specific by intent. Verify first that the host version you need has definitions in the repository, since the README says some release versions are missing either because nothing changed in the API or because nobody added them, and read the generation caveats before you trust the definitions for a script that must not crash a user's session.

## FAQ

### How do I use types-for-adobe in a TypeScript script for Illustrator?

Install the package with npm i types-for-adobe, create a tsconfig.json with module set to none and noLib true, and add a reference directive pointing at the product and version you target, for example types-for-adobe/Illustrator/2015.3. Then compile with tsc and run the output from the host application.

### Why are there different type definitions for each version of an Adobe app?

The README says the repository maintains a history of typedefs for each given version of each host app, so a tool can target a specific version and avoid using features introduced later. For commercial tools a slightly older target means wider adoption, and for internal tools it matches a company-mandated version.

### Are the type definitions generated or written by hand?

Both. Some were generated with an extendscript-xml-to-typescript converter that converts scripting dictionaries, though the README notes this only works for a few select apps and has produced incorrect data in some cases. Others were written by hand using Adobe's release announcements and API exploration.

### Why is a version of an Adobe app missing from types-for-adobe?

The README gives two reasons: there have not been any API changes for that version, or nobody has taken the time to add typedefs for it, in which case a pull request is welcome.

## Sources

- [docsforadobe/Types-for-Adobe on GitHub](https://github.com/docsforadobe/Types-for-Adobe)
- [Issues](https://github.com/docsforadobe/Types-for-Adobe/issues)
- [License: MIT](https://github.com/docsforadobe/Types-for-Adobe/blob/master/LICENSE)
- [README](https://github.com/docsforadobe/Types-for-Adobe/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/docsforadobe-types-for-adobe