RESTDataSource implementation issue with willSendRequest & @apollo/utils.withrequired is a devDependency

[AvivonCtrl]

While implementing RESTDataSource, following the example of willSendRequest from the official documentation (https://www.apollographql.com/docs/apollo-server/data/fetching-rest/#setting-a-header) I encountered the following problems:

1. The type signature for willSendRequest mentioned in the documentation is incorrect. The actual type signature can be found in the source code (https://github.com/apollographql/datasource-rest/blob/main/src/RESTDataSource.ts#L242):

protected willSendRequest?(
    path: string,
    requestOpts: AugmentedRequest,
  ): ValueOrPromise<void>;

2. The @apollo/utils.withrequired is a devDependency, causing type resolution issues for new projects. The WithRequired type is undefined, requiring me to install @apollo/utils.withrequired as a dependency in my project for AugmentedRequest to be resolved correctly.
   • This is also true forisPlainObject from lodash.isplainobject

[trevor-scheer]

@AvivonCtrl I was able to reproduce the issue with willSendRequest and @apollo/utils.withrequired. But the isPlainObject part isn't relevant to the public API so I'm not sure how that's problematic for a package consumer (and I couldn't reproduce).

Can you share a reproduction with me?

[AvivonCtrl]

@AvivonCtrl I was able to reproduce the issue with willSendRequest and @apollo/utils.withrequired. But the isPlainObject part isn't relevant to the public API so I'm not sure how that's problematic for a package consumer (and I couldn't reproduce).

Can you share a reproduction with me?

Just mentioned the isPlainObject, it is indeed not relevant.

[AvivonCtrl]

Should be noted that the documentations on the website right now are misleading and the code samples there are incorrect.

[trevor-scheer]

Thanks @AvivonCtrl, I did try to correct those - the referenced PR immediately above this comment should have fixed the outstanding issues (I landed it a couple days ago but typed the reference to this issue incorrectly so it didn't link).

Is there still misleading documentation somewhere or is that what you were referring to?