Repository: TypeScript
Issue: Design Meeting Notes, 6/11/2024
Labels: Design Notes

# Syntactic Form for Preserving Computed Property Names

https://github.com/microsoft/TypeScript/pull/58829

* When you have `isolatedDeclarations`, you can't use computed property names in object literals and classes.
    * They transform into different forms depending on the type (symbol, string types, etc.).
* We basically said they're not supported under `isolatedDeclarations`.
* This proposal is to support computed property names under `isolatedDeclarations` by introducing a new syntactic form.

  ```ts
  export const obj = {
    [someValue satisfies keyof]: 123,
  };
  ```
* Idea is this should be transformed into the following declaration file:

  ```ts
  export declare const obj: {
      [someValue]: number;
  };
  ```
* Under this, `someValue` must be a singleton/unit type.
* What is the specific use-case here?
    * Need to preserve the exact syntax input by the user - codebases with computed properties can't use `isolatedDeclarations`.
* Do we really need new syntax for ID?
* Why can't we just error in cases when an "optimistic inference" would not succeed?
    * We didn't feel okay doing optimistic inference in general.
* Why can't we just emit the expression as-is always?
    * A computed property resolves differently depending on ambient vs. non-ambient contexts.
    * Also, we'd need to now preserve the declaration of more non-exported values.
        * We do that for `typeof` anyhow.
    * In general, it's a breaking change.

# Only Look up `type` from `package.json` when in `node_modules` (and in `node16`)

https://github.com/microsoft/TypeScript/pull/58825

* Got feedback on a feature that we added in 5.5 where we look up `package.json`.
* Two issues reported.
    * First: dual-publish. CJS and ESM.
    * Second: script file that really wasn't meant to be driven by a `package.json` farther up the spine.
    * Third: doing all this work causes a lot of file-watching.
* A few options:
    * Revert all of this.
    * Only expand the behavior to modules inside of `node_modules`.
    * Roll with it.
* How does it work with monorepos with symlinked dependencies in `node_modules`?
    * Seems like it plays "correctly" - we always go through `realpath` and figure out where the actual file is.

# Analyze Control Flow Effects of Callbacks

https://github.com/microsoft/TypeScript/pull/58729

* Considered a strictness flag - but feels like maybe this should be the default.
* Issues around the `Deferred` helper conflicting with libraries using this type.
    * Using a type helper probably communicates the wrong thing as ewll.
* What's the work-around for when the caller doesn't mark something as `deferred`?
    * Define a helper function called `deferred` that just takes and returns the function.

      ```ts
      function deferred<T extends (...args: any[]) => any>(deferred fn: T): T {
          return fn;
      }
      ```
* All the examples of new breaks running over GitHub are kind of expected - places where `deferred` will need to be added.
    * But which of these are wins?
    * Maybe the `tinacms` examples.
    * And Pyright has a missing non-null assertion.
* What happens if you mark a parameter as `deferred` and it's not deferrable?
    * We could error on that.
* Some have asked about why we only do this for function expressions and not declarations (or constants initialized to function expressions).
    * Easier to explain, visually shows up.
    * And it would be a *whole* lot more analysis.
    * And then issues around circularities due to resolving each name.
* Does `deferred` affect assignability?
    * Right now we don't do anything special.
    * Currently it's an intrinsic type that doesn't affect assignability.