I took a peek at the implementation - I think this only works for a case where the typing explicitly contains the string "Promise". For example, I don't think it would work if I use `SomeInterface["some_promise_key"]` or might incorrectly add an async if I use `Awaited<Promise<...>>`.
I think what you're trying to build might be best served by Typescript's VFS - https://www.npmjs.com/package/@typescript/vfs. You can load the local files into an in-memory type system, and quickly extract async/await hints that might be more useful for a typical TS developer. I think there's a lot of really interesting static analysis you could do to improve async/await safety, as it certainly leads to issues from time to time.
bastawhiz · 20h ago
Is this a problem that people actually have?
joshstrange · 20h ago
I do not want to be mean but I think you'd be much better served with ESLint rules to yell at you when you don't await when you should or do when you shouldn't.
This should _not_ be an automatic operation since it can change behavior in ways that will be unclear to the developer (completely undoing any gain from them being added automatically).
theThree · 19h ago
You can still control it by adding "//no-await". In fact, the "//no-await" makes me feel more clear.
I think what you're trying to build might be best served by Typescript's VFS - https://www.npmjs.com/package/@typescript/vfs. You can load the local files into an in-memory type system, and quickly extract async/await hints that might be more useful for a typical TS developer. I think there's a lot of really interesting static analysis you could do to improve async/await safety, as it certainly leads to issues from time to time.
This should _not_ be an automatic operation since it can change behavior in ways that will be unclear to the developer (completely undoing any gain from them being added automatically).