Syntactic Form for Preserving Computed Property Names

#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.

  export const obj = {
    [someValue satisfies keyof]: 123,
  };

• Idea is this should be transformed into the following declaration file:

  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)

#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

#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.

    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.