With eslint/eslint#12246 in mind (V8 providing better stack traces for return await) would it make sense to have a new return-await rule with a 'never' | 'in-try-catch' | 'always' option?

Yes i think that'd make more sense @ark120202. @bradzacher what are you thoughts on that change should I update the feature request?

To clarify then,

The idea would be to have a rule (return-await) which bans directly returning await statements (return await foo) (i.e. requires no type info), except in the case that you're returning a promise from within a try/catch, in which case you want to enforce that you return an await (i.e. requires type info).

Seems like a good candidate for this plugin.

declare function returnsPromise(): Promise<string>;
declare function handleException(e: Error): string;

// option: 'in-try-catch'
async function myFunc1(): Promise<string> {
  try {
    return returnsPromise(); // lint error - should await the promise so errors are handled by the surrounding try/catch
  } catch (e) {}
  return Promise.resolve('foo'); // no error
}

// option: 'never'
async function myFunc1(): Promise<string> {
  try {
    return await returnsPromise(); // lint error - should never return await
  } catch (e) {}
  return await Promise.resolve('foo'); // lint error 
}

// option: 'always'
async function myFunc1(): Promise<string> {
  try {
    return returnsPromise(); // lint error - should always await promise
  } catch(e) {}
  return Promise.resolve('foo'); // lint error 
}

that's what i was thinking, yeah! @ark120202 is the snippet above what you were thinking for this?

Yeah, that sounds good to me!
One thing I'm not really sure is 'never', since currently no-return-await doesn't disallow it in try catch (but doesn't enforce it as well). So if compatibility with no-return-await is one of goals it has to be allowed.

I'm actually okay with that since the same could be said for the always rule (in terms of incompatibility with no-return-await). I think if we make the default in-try-catch then we avoid this issue for most users. It feels appropriate to expect users with customized rules to have to be more careful in understanding how those rules will interact.

@bradzacher so in terms of next steps should i put together a pr that references this issue? I haven't worked on a codebase like this in the past but I'd be happy to give it a go

Actually, in that case is there a need for 'never' at all? I have originally proposed it to be more compatible with no-return-await, but I agree that there's no reason to pursue that. Would someone really want to disallow return await even in try catch?

hmm interesting thought. Performance critical applications i suppose, but even then this is a pretty narrow optimization. @bradzacher did you have a particular use case in mind or just for consistency purposes?

consistency, warding off people asking for it.

I can pretty easily see an argument that people don't want return await ever, and would rather a variable assignment that gets returned a la

async function myFunc1(): Promise<string> {
  try {
    const res = await returnsPromise();
    return res;
  } catch (e) {}
  const res = await Promise.resolve('foo');
  return res;
}

Not sure - it's probably the easiest case to support, so I figure there's little overhead to supporting it.

so in terms of next steps for this, should I open a PR?

Definitely - if you see value in this and want it sooner, rather than later!

It's always a lot faster and better for us if users PR the features we want; either we maintainers can try to write PRs for the ~180 issues in the repo, or we can review PRs for those issues. The latter is more scalable and easier.

sounds good ill get to work on this, this weekend!