Ron Buckton
Ron Buckton
> This would address (at least partially) #50196 , cc @phryneas Per @RyanCavanaugh's [comment](https://github.com/microsoft/TypeScript/issues/50196#issuecomment-1206637336) in #50196, the biggest issue with future extensibility would be how people choose to depend on...
Another scenario I'd investigated recently was how a library could ensure that specific compiler options are set for it to be used correctly: ```ts // @exactOptionalPropertyTypes: false interface TypeScriptSettingsError {...
And here is a similar example to the previous one, utilizing `TypeScriptSettings["locale"]` to provide a localized error message: ```ts // @exactOptionalPropertyTypes: false // @locale: fr-FR interface TypeScriptSettingsError { error: Message...
> Hmm, I have mixed feelings about the name `ReadonlySetLike`. While I get it--it doesn't have any of the mutating methods--it'd be weird (and maybe a bit misleading, for people...
I would be happy with either a lower-level building block here, or even a standardized, symbol-based event protocol that could sit on top of `EventTarget`/`EventEmitter`, assuming we could iron out...
We've considered something similar for Promises in TypeScript, and may do something similar for both in the future. The `typescript-eslint` plugin for ESLint has a [`no-floating-promises`](https://typescript-eslint.io/rules/no-floating-promises/) rule for Promises currently,...
In lieu of type information, a linter could at the very least have heuristics to recognize well-known host APIs that will produce disposables, such as `fs.promises.open()`.
We ran into issues with this in committee when promoting `throw` expressions. An arbitrary statement in an expression position most likely won't make it to Stage 3. After discussing this...
@ljharb: no unnecessary block scope, less boilerplate.
> `do ()` could avoid the scope; I find the explicit `do` pretty important to avoid confusion and make intentions clear. Consider that there's little difference between `` `(` Expression...