Preserve computed property in `--isolatedDeclarations` emit

[acutmore]

🔍 Search Terms

isolated declarations, computed properties

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Now that #60052 allows for (some) computed properties in in .d.ts files I think the next step is for --isolatedDeclaration to be updated to not error and to emit the computed properties. Opening this issue if helpful to track this work.

I believe the previous plan (#58800) to introduce a new syntactic marker is no longer required.

Related issues: #58533 #60818 #61068

📃 Motivating Example

export const prop: unique symbol = Symbol();

export class MyClass {
    [prop] = () => Math.random();
}

@isolatedDeclarations: false

playground

export declare const prop: unique symbol;
export declare class MyClass {
    [prop]: () => number;
}

@isolatedDeclarations: true (current 🙁)

playground

ts(9038) Computed property names on class or object literals cannot be inferred with --isolatedDeclarations.

export declare const prop: unique symbol;
export declare class MyClass {
}

@isolatedDeclarations: true (future 🚀 )

No error and same emit as @isolatedDeclarations: false

export declare const prop: unique symbol;
export declare class MyClass {
    [prop]: () => number;
}

💻 Use Cases

The primary use case is enabling isolated declarations at scale on large codebases that make heavy use of computed properties.

[bradzacher]

I was actually about to post in the discord about this!

In the canva codebase we have:

import { $mobx, IAtom } from 'mobx';

export class Foo1 {
  readonly [$mobx]: IAtom = ...;
}

Where $mobx is declared as export declare const $mobx: unique symbol;

Currently TS errors on this code, but I don't see how you can resolve this error at all.

[bradzacher]

Question: is there a way around this?
I am trying to rollout ID to our codebase at Canva but it looks like I'm blocked by this.

[TJLSmith0831]

Working on my OSS contributions. Mind if I give this a shot?

[bradzacher]

I found this VERY HACKY workaround for now:

import { $mobx, IAtom } from 'mobx';

export interface Foo {
  [$mobx]: IAtom;
}
export class Foo {
  constructor() {
    this[$mobx] = ...;
  }
}

It's ugly but it works and unblocks me for now, at least.

[teague2]

For anyone alse struggling with isolatedDeclarations i finally got something similar to work.
I was using mixins and had to figure out a way to dynamically create brand mixin classes.
I'm sure there is a simpler solution but the BrandedClass return type fixed most of the issues.

type BrandedClass = {
  new (): {}; // this could be any interface
  isBrand: (value: unknown) => boolean;
};

export const Branded = (config: { brand: string }): BrandedClass => {
  const brand: unique symbol = Symbol.for(config.brand);
  return class {
    readonly [brand]: boolean = true;
    static readonly [brand]: boolean = true;
    static isBrand(value: unknown) {
      return isBranded(value, config.brand);
    }
  };
};

export function isBranded(value: unknown, brand: string): value is BrandedClass {
  const brandSymbol = Symbol.for(brand);
  return value !== null && typeof value === 'object' && brandSymbol in value && value[brandSymbol] === true;
}

[bradzacher]

@teague2 if you use a #private property then it should act like a brand as well. True private properties essentially make a class declaration a nominal type then your brand check can just be this.#brand === config.brand