Plugin method types shouldn't force users to return a promise

[stretchkennedy]

Back in v3, most plugin methods (requestDidStart etc.) were unified to always return a promise. This means that instead of

class LoggingPlugin implements ApolloServerPlugin<MyContext> {
  requestDidStart() {
    const start = hrtime.bigint()
    return {
      willSendResponse () {
        console.log('completed in', (hrtime.bigint() - start) / BigInt(1000000), 'ms')
      }
    }
  }
}

users have to do

class LoggingPlugin implements ApolloServerPlugin<MyContext> {
  async requestDidStart() {
    const start = hrtime.bigint()
    return {
      async willSendResponse () {
        console.log('completed in', (hrtime.bigint() - start) / BigInt(1000000), 'ms')
      }
    }
  }
}

This has the following disadvantages:

1. In a larger example, using async for code that will never await anything can be confusing. "Why does this code need to be async, is there a bug, has it changed?"
2. It probably has a performance impact.
3. You can write plugins without async in JavaScript and they'll work fine, which makes porting them to TypeScript confusing.
4. If JavaScript plugins work fine with non-promise returns but the TS types don't reflect this, there's a risk of breaking existing plugins if future behaviour comes to rely on the return type being a promise.

I promise I actually wrote this feature request and it's not some LLM slop. I just finished porting some of our plugins to TS at work, and I found this API confusing. It's not a huge deal but it would make the ergonomics of the library nicer.

[vishwakt]

Hello @stretchkennedy

I've just opened a PR to address this issue! I totally agreed that forcing plugins to be async was a bit of a DX hurdle for purely synchronous operations.

What I did:

• Introduced a PromiseOrValue<T> type and exported it in the public API.
• Replaced Promise<T> with PromiseOrValue<T> on the ApolloServerPlugin methods and listener hooks.
• Updated the internal invokeHooks utilities to seamlessly handle both Promises and synchronous values without altering the core execution behavior.
• Added explicit unit tests to guarantee synchronous plugin methods compile and execute correctly.

Since this is strictly widening the types, it's fully backwards-compatible. Feel free to take a look at the PR whenever you have a chance, and let me know if any tweaks are needed!

[stretchkennedy]

@vishwakt It looks like it would solve the problem, but I don't have any relationship to the Apollo team and you'd probably need one of them to review your work, check the tests pass, reason about the consequences and direct of doing this, etc.