5 ms·
Automatically add missing "async/await" keywords to your TypeScript code
- bastawhiz 1y agoIs this a problem that people actually have?
- gotoeleven 1y ago[flagged]
- xeromal 1y agoFun side project man!
- primitivesuave 1y agoI 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 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.
- joshstrange 1y agoI 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 1y agoYou can still control it by adding "//no-await". In fact, the "//no-await" makes me feel more clear.
- nextweek2 1y agoI created a ticket, using comments is not necessary because there is already the `void` syntax for when you don't want to wait: https://github.com/stanNthe5/typescript-autoawait/issues/1 https://github.com/stanNthe5/typescript-autoawait/issues/1
- nextweek2 1y agoIt should be noted that there is already a lint rule for this: https://typescript-eslint.io/rules/no-floating-promises/ https://typescript-eslint.io/rules/no-floating-promises/