Repository: TypeScript
Issue: Design Meeting Notes, 5/3/2024
Labels: Design Notes

# Returnless functions in `isolatedDeclarations`

https://github.com/microsoft/TypeScript/issues/58330

```ts
/** Inferred as void */
export function f() {
    g();
}

/** Inferred as never */
export const x = () => {
    g();
};

function g(): never {
    throw null;
}
```

* Which is preferable: making declarations and expressions have consistent behavior under `--isolatedDeclarations`, or support better ergonomiccs on `isolatedDeclarations`?
* Under isolated declarations, we may "unnecessarily" require you to annotate `f` as `void`.
    * This is only because of consistency with function expressions, where they may be inferred as `never`.
* The rules for when we infer `never` in a function expression are well-established.
    * Will we ever want to change it?
        * Uhhhh...
* Why did we do that?
    * We didn't want to break code that throws and then gets overridden, or is then 
* If we did this, we'd likely be locking down our behavior.
    * Every other tool would have to change behavior if we change our minds.
* Maybe - that said, we'd never change these to be `never`, we'd change them to only possibly be `undefined`.
* We really like the idea of keeping design room open to ourselves. So we'll keep the consistency of saying "you must write `void` here".

# Expose a subset of current compiler options to type system

https://github.com/microsoft/TypeScript/pull/58396

* #50196 was proposed.
    * Related: `@phryneas/ts-version`, a package that leverages `typesVersions` to tell you what version of TS you're on.
    * People trying to do things like this to figure out certain compiler options.
* We want to discuss how this relates to using a flag for `TReturn`/`TNext` in `Iterable`/`IterableIterator`, as well as broader use cases and determine if this is a direction we want to take, which options to expose, and what to name the type.
* This work could allow `lib.d.ts` (or others) to decide on the type of `TReturn`/`TNext`, or types of other things, based on `--strictNullChecks`, `--noImplicitAny`, etc.
* Lots of examples using `TypeScriptSettings extends { strictFunctionTypes: T } ? T : never` or similar. Why not just `TypeScriptSettings["strictFunctionTypes"]`?
    * Code where `TypeScriptSettings` is forward-declared, maybe doesn't have a given option.
        * But now you can accidentally use a flag that doesn't exist (misspelled flag names).
* People've asked for this for a long time - but conditional compilation makes things extremely hard to diagnose.
* Ability for misuse is high with this. Shipping it is a green light to tell people to use it.
    * Misspelling options was one example.
    * Exposing `lib` - is `lib` really the right way to go about this?
* `typesVersions`
* Very broad, but not powerful enough to express places where conditional compilation doesn't solve big problems.
    * e.g. global variable that depends on context.
* Fair points - main interest was specific type-checking options.
* Is it good if someone turns on `noImplicitAny` and that affects some code in a clever way?
* Regarding "shipping it is a green light to tell people to use it": could name it `__TypeScriptSettingsDoNotUse`?
    * `TSCONFIG_YOU_WILL_BE_FIRED`
* How does this atually solve things for `TReturn`/`TNext`?
    * ```ts
      type BuiltinIteratorReturn<T> = TypeScriptSettings["noUncheckedIndexedAccess"] extends true ? T | undefined : T;
      ```
* Feels like we are not getting enough of a positive read from this approach. We get the use-cases, but the potential downsides are too big.

# Have a consistent position for where some errors are reported

#57842

* Have open question of what position to use and in which files.
* We've had issues about diagnostic positions which change depending on which syntax nodes get checked first.
    * For example, we have `Cannot find module '@emotion/react/jsx-runtime' or its corresponding type declarations.` that will be reported on the first place we check.
    * But that could be issued in a file that's not even open!
    * Could say this is a global error with no span, we could say that it's done once per file.
    * Technically this specific error shouldn't be a global error! It's file-specific.
* Another with `This syntax requires an imported helper but module 'tslib' cannot be found.`.
    * This is a global error, but it's reported in the first file that gets checked.
    * Arguably, this is also per-file.
* It would be good if the CLI deduplicated many of these. Let's clean this all up first.