Contextual defaults in ctx.octokit endpoints

[nickofthyme]

Feature Request

⚠️ I know this is a big ask, but I just wanted to put it out there if nothing else to get others input.

Is your feature request related to a problem? Please describe.
Not really more of an inconvenience. Using the repo, issue and pullRequest helper methods when calling octokit endpoints via context is super helpful but can become tedious. I wonder if there is a way to have contextual defaults that apply defaults to each endpoint based on the given event context. The current API looks something like...

app.on("issues.opened", async (context) => {
  context.octokit.issues.createComment(context.issue({
    body: "Obrigado por abrir esta issue!",
  });
});

Describe the solution you'd like

Instead of the above example you would just have the following, without the need for context.issue, something like...

app.on("issues.opened", async (context) => {
  context.octokit.issues.createComment({
    body: "Obrigado por abrir esta issue!",
  });
});

This way depending on the event context, it tries to fill in the likely defaults for each endpoint. This example is hardly changed but in a large app with many places it could be a lot. These defaults can always be overridden by simply passing a different value.

app.on("issues.opened", async (context) => {
  context.octokit.issues.createComment({
    issue_number: 123, // <---- override
    body: "Obrigado por abrir esta issue!",
  });
});

It doesn't look like this type of endpoint defaults are supported nicely using @octokit/core out of the box like it is currently being used...

probot/src/octokit/probot-octokit.ts

Lines 41 to 58 in 3d30acc

	export const ProbotOctokit = Octokit.plugin(
	throttling,
	retry,
	paginateRest,
	legacyRestEndpointMethods,
	enterpriseCompatibility,
	probotRequestLogging,
	config
	).defaults((instanceOptions: any) => {
	// merge throttle options deeply
	const options = Object.assign({}, defaultOptions, instanceOptions, {
	throttle: instanceOptions.throttle
	? Object.assign({}, defaultOptions.throttle, instanceOptions.throttle)
	: defaultOptions.throttle,
	});
	return options;
	});

And it could possibly take some changes in @octokit/core and others to provide better support for this at a top-level and not just per endpoint.

[gr2m]

what you suggest would implicitly set parameters which might cause all kind of unwanted problems.

Something that might help better is to implement a chainable API, like

const issueOctokit = octokit.issue({ owner, repo, issue_number })

when you could do something like this

issueOctokit.createComment({ body })

and we could even pass issueOctokit as part of the context. I think there is a discussion about it somewhere that is 5+ years old. It could be implemented as a plugin, as an alternative to https://github.com/octokit/plugin-rest-endpoint-methods.js, but it would take a lot of work to build. If anyone wants to tackle it, you can build a community plugin and we can consider promiting to an official plugin later, and maybe adopt in in Probot.

GitHub

GitHub - octokit/plugin-rest-endpoint-methods.js: Octokit plugin adding one method for all of api.github.com REST API endpoints

Octokit plugin adding one method for all of api.github.com REST API endpoints - GitHub - octokit/plugin-rest-endpoint-methods.js: Octokit plugin adding one method for all of api.github.com REST API...

[nickofthyme]

Thanks, good to know!

I can see your point where the implicit params may cause unwanted problems but to me those seems like edge cases is rare circumstances where overrides can always fix them.

Take for instance the context.repo() this is likely the default for most of the requests under octokit.repos, same for context.pullRequest() and octokit.pulls and many others.

But adding them individually to the context via a plugin is a pretty good compromise.