Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support async operation handler resolver #921

Merged
merged 1 commit into from
Jun 2, 2024

Conversation

mdmower-csnw
Copy link
Contributor

@mdmower-csnw mdmower-csnw commented May 29, 2024

  • Let users define operationHandlers.resolver as a synchronous or asynchronous function that returns a request handler
  • Make installOperationHandlers an asynchronous function that awaits a resolver promise (automatically wraps resolver with promise if needed)
  • Update operation handlers middleware to handle an async installOperationHandlers.

This is similar to the approach mentioned in #660 but makes it possible to use await import() in the resolver so that a new request handler doesn't have to be created as a wrapper. Then, the default resolver requires very little modification. I was able to replace

const modulePath = path.join(handlersPath, baseName);
if (!tmpModules[modulePath]) {
tmpModules[modulePath] = require(modulePath);
}
const handler = tmpModules[modulePath][oId] || tmpModules[modulePath].default[oId] || tmpModules[modulePath].default;
with

// import {pathToFileURL} from 'node:url';

const modulePath = path.join(handlersPath, baseName);
const moduleUrl = `${pathToFileURL(modulePath).toString()}.js`;
const importedModule = (await import(moduleUrl)) as Record<string, RequestHandler | undefined>;

const handler = importedModule[oId];

and otherwise use the default resolver as-is.

- Let users define operationHandlers.resolver as a synchronous or
  asynchronous function that returns a request handler
- Make installOperationHandlers and asynchronous function that awaits a
  resolver promise (automatically wraps resolver with promise if needed)
- Update operation handlers middleware to handle an async
  installOperationHandlers.
@cdimascio cdimascio merged commit a4a7175 into cdimascio:master Jun 2, 2024
5 checks passed
mdmower-csnw added a commit to CSNW/express-openapi-validator that referenced this pull request Aug 30, 2024
In cdimascio#921, a stronger type applied to OperationHandlerOptions['resolver']
so that end users would have an idea of what the parameters are for
their custom resolvers. It went too far in stipulating a return type.
Set the return type to unknown and let users decide how much type safety
they need in their resolver.

Fixes cdimascio#952
cdimascio pushed a commit that referenced this pull request Aug 31, 2024
In #921, a stronger type applied to OperationHandlerOptions['resolver']
so that end users would have an idea of what the parameters are for
their custom resolvers. It went too far in stipulating a return type.
Set the return type to unknown and let users decide how much type safety
they need in their resolver.

Fixes #952
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants