Skip to content

Illustrator enum-like types #161

@MBecherKurz

Description

@MBecherKurz

Hi everyone,

I'm currently reading through the official Illustrator 2026 type definition document and may open a PR for it in the future. While looking into it, I noticed that all enum-like object are currently modeled as plain TypeScript enums. From my understanding, that does not accurately reflect Illustrator/ExtendScript runtime behavior.

Example

ScreenMode is currently defined like following:

/** The screen mode. */
declare enum ScreenMode {
  /** Full screen with menu bar. */
  DESKTOP = 2,
  /** Full screen without menu bar. */
  FULLSCREEN = 3,
  /** Display multiple windows. */
  MULTIWINDOW = 1,
}

This implies that ScreenMode.DESKTOP and the number 2 are interchangeable. However, does not seem to be the case at runtime.

If we run following ExtendScript:

alert(ScreenMode.DESKTOP);
alert(ScreenMode.DESKTOP == 2);
alert(typeof ScreenMode.DESKTOP);

the results are:

  • "ScreenMode.DESKTOP"
  • "false"
  • "object"

So ScreenMode.DESKTOP is not equal to 2 and more importantly, it is not even a number.

Why I think this is problematic:

With the current type definition, code like this is allowed:

app.activeDocument.activeView.screenMode = 2; // No type error

However this fails at runtime with: Error: Enumerated value expected

Suggestion

I think a branded/object-based representation would be closer to the actual ExtendScript behavior, for example:

declare const __brand: unique symbol;
type Enumerable<TName> = {
  readonly [__brand]: TName;
};

type ScreenMode = Enumerable<"ScreenMode">;
declare const ScreenMode: {
  readonly DESKTOP: ScreenMode;
  readonly FULLSCREEN: ScreenMode;
  readonly MULTIWINDOW: ScreenMode;
};

This would prevent assigning arbitrary numbers and would make the typings stricter and, in my opinion, more accurate.

I’d be happy to open a PR for Illustrator at least, since I have not yet checked how this behaves in other Adobe applications.

Before doing that, I wanted to ask whether the current approach was a deliberate design decision, or whether changing this would be welcome.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions