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

add Promise version overload for FastifyPlugin #2350

Merged
merged 1 commit into from Jul 10, 2020

Conversation

lundibundi
Copy link
Contributor

Checklist

  • run npm run test and npm run benchmark
  • tests and/or benchmarks are included
  • commit message and code follows Code of conduct

I usually write TS with no-misused-promises rule on since it provides such benefits as prohibiting passing async function where it is not expected (i.e. event listener on EventEmitter etc.)
The fastify.register didn't have a correct overload for a plugin function that returns a promise therefore that rule failed even though such use-case is supported.

This adds an overload to FastifyPlugin that returns a Promise, therefore, telling TS that register can handle such functions.

Unfortunately, I couldn't get TS to properly infer types for async versions of functions, therefore a need to explicitly specify type. Furthermore, since the type was explicitly defined on FastifyPlugin.instance TS refused to accept just FastifyInstance type for instance argument on plugin function and I had to change the signature of FastifyPlugin to accept any extension of FastifyInstance.
Definitely want to hear @Ethan-Arrowood opinion on this.

@Eomm Eomm added the typescript TypeScript related label Jun 25, 2020
Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good for me.

): void;
export type FastifyPlugin<Options extends FastifyPluginOptions = {}, FI extends FastifyInstance = FastifyInstance> =
{
(instance: FI, opts: Options, next: (err?: FastifyError) => void): void;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the type for the err parameter should be Error.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's unchanged from how it was before.
I can change it here but I guess a separate PR would be better.

Copy link
Member

@delvedor delvedor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@delvedor delvedor added the v3.x Issue or pr related to Fastify v3 label Jun 27, 2020
@Ethan-Arrowood
Copy link
Member

Ethan-Arrowood commented Jun 27, 2020

This looks good! I won’t be back at my laptop until Monday, so I can’t check it out locally. I’m not totally following what’s happening with the instance argument and FastifyInstance but I’ll be sure to revisit that on Monday 😄

@lundibundi
Copy link
Contributor Author

I’m not totally following what’s happening with the instance argument and FastifyInstance

A little clarification, there are 2 issues here

  • TS refuses to infer types for async function (instance, opts) { } and such, I don't know why
  • When .register used with function with type instance: FastifyInstance TS doesn't consider type FastifyInstance<RawServerBase, RawRequestDefaultExpression<RawServerBase>, RawReplyDefaultExpression<RawServerBase>> (on FastifyPlugin) to be compatible with just FastifyInstance.
    i.e. function function plugin(instance: FastifyInstance, opts: FastifyOptions) cannot be passed to .register().
    So I added the FI extends FastifyInstance thingy so it would allow that - this is separate from the first point and would be useful on its own (though is there a better way to do it?)

@Ethan-Arrowood
Copy link
Member

TS refuses to infer types for async function (instance, opts) { } and such, I don't know why

I'm checking this out locally and I see what you mean now. I'm going to dig in and try to figure this out. I've hit this before and I don't remember the solution. Have you tried opening a Stackoverflow question for it? I usually get good responses to my TypeScript questions

@Ethan-Arrowood
Copy link
Member

Ethan-Arrowood commented Jun 29, 2020

Aha! microsoft/TypeScript#32571 - lets see what they reply. I don't know if there exists a work around at this time. Maybe your current generic inference is the best path but lets see.

@Ethan-Arrowood
Copy link
Member

Ethan-Arrowood commented Jun 29, 2020

Another bit of relevant information of why the generics are defined as they are now: fastify/fastify-plugin#85

I believe it has to do with assumptions on external plugins

This comment in particular might help here: fastify/fastify-plugin#85 (comment)

Sorry there is so much to this, plugins have been the hardest thing to define types for 😅

--

I think I understand what you are trying to do with the instance inference. My assumption was that when creating a plugin the user would specify its type as FastifyPlugin like the test plugin:

interface TestOptions extends FastifyPluginOptions {
  option1: string;
  option2: boolean;
}

const testPlugin: FastifyPlugin<TestOptions> = function (instance, opts, next) { }

To summarize and highlight the previous discussion, plugins should be written in a way that does not require the instance to be specified, and they should handle any of the possible standard instance configurations (http vs https vs http2).

Correct me if I'm wrong, but i believe the generic inference you've implemented is a different way of achieving type casting i.e. you can achieve the same types by doing this in your implementation:

fastify().register(function (_inst, opts, next) {
  const instance = _inst as FastifyInstance
}))

This is considered safer than the generic inference because its more obvious and intentional.

I'm going to reject your change for specifying the instance type, but you're on to something with the promise one. And I think I have a work around in mind (will share in a new comment).

Copy link
Member

@Ethan-Arrowood Ethan-Arrowood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also remove the instance inference per my previous comment.

export type FastifyPlugin<Options extends FastifyPluginOptions = {}, FI extends FastifyInstance = FastifyInstance> =
{
(instance: FI, opts: Options, next: (err?: FastifyError) => void): void;
} | {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets break these apart into two separate types or interfaces. Call them FastifyPluginSync and FastifyPluginAsync. Update FastifyPlugin to be FastifyPluginSync | FastifyPluginAsync (pass through the options generic_, and make sure to export all three of these types. In the test file create a new test plugin that is specified by the FastifyPluginAsync type and pass it to register.

This should fix the async bug and enable users to safely type their plugins.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's call them FastifyPluginCallback and FastifyPluginAsync. No one is sync.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will try this out, looks good.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@lundibundi
Copy link
Contributor Author

To summarize and highlight the previous discussion, plugins should be written in a way that does not require the instance to be specified, and they should handle any of the possible standard instance configurations (http vs https vs http2).
Correct me if I'm wrong, but i believe the generic inference you've implemented is a different way of achieving type casting i.e. you can achieve the same types by doing this in your implementation:

@Ethan-Arrowood Completely agree that plugins should be agnostic to specific fastify instance (until such segregation is supported explicitly).
My idea\concern was with passing a generic function of async function plugin(instance: FastifyInstance, opts: FastifyPluginOptions) (notice just FastifyInstance as type) to .register() which current types didn't allow me to do. And IMO it sould be allowed as the FastifyInstance is just a generic type over all instances or at least should be IIUC.
Did I perhaps type something it wrong and it is supported (I just added those types in fastify-cli generate --lang ts project)?

@Ethan-Arrowood
Copy link
Member

Ethan-Arrowood commented Jun 29, 2020

which current types didn't allow me to do

This is intentional. FastifyInstance stand alone is not generic for all server types. It defaults to http. If this is the type of instance you want in your plugin then we recommend using the safer, type casting pattern. If you want a FastifyInstance generic to all server types you should use the existing FastifyPlugin implementation to define your plugin function.

@lundibundi
Copy link
Contributor Author

@Ethan-Arrowood Oh, I've misunderstood the idea then. My intent was to just type generic to all server types plugin function to export it from a file. Like function in template plugins/support.ts and example/index.ts which uses FastifyInstance which is why I thought that it should be generic to all instances. Does this mean that that template should be changed?

Also, wdyt of adding a separate type of FastifyInstanceAny (or any other name) to specifically denote any instance of fastify and explicitly use it in plugin types, so that it would be possible to properly type such function without relying on type inference or as FastifyPlugin?

@Ethan-Arrowood
Copy link
Member

Hmm yes it does look like the cli template should be updated. If you'd like to send a PR for that too it would be appreciated!

To be honest I'm not sure about a FastifyInstanceAny type. But i'm also not totally against it. Maybe in a separate issue+pr you can add that and we can see what consensus we land on with other contributors?

Copy link
Member

@Ethan-Arrowood Ethan-Arrowood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good! Can you try and replace the | operator with &

I got a simplified playground to work with this. I'm hoping it work for us here too!

@lundibundi
Copy link
Contributor Author

@Ethan-Arrowood that breaks type inference for both callback and async (already broken) versions unfortunately:
Screenshot from 2020-07-01 22-54-09

I think that's due to that async TS bug.

@Ethan-Arrowood
Copy link
Member

Ethan-Arrowood commented Jul 1, 2020

Hmm really? And all you did was change the | to &? Okay I'll try it locally. Apparently the bug has been fixed (TS maintainers commented back) I just expanded my playground and yeah can confirm this is not a solution. Ugh it seems like its only issue when you inline the async function. I'll make a note to open an issue on TypeScript about this

@Ethan-Arrowood
Copy link
Member

One last trial: playground try this kind of function overloading please

@lundibundi
Copy link
Contributor Author

Not sure if I correctly understood the idea:

diff --git a/test/types/plugin.test-d.ts b/test/types/plugin.test-d.ts
index b8c7f04..065719c 100644
--- a/test/types/plugin.test-d.ts
+++ b/test/types/plugin.test-d.ts
@@ -40,9 +40,9 @@ const testPluginAsync: FastifyPluginAsync = async function (instance, opts) { }
 expectAssignable<FastifyInstance>(fastify().register(testPluginAsync, {}))
 
 // TODO: Uncomment when https://github.com/microsoft/TypeScript/issues/32571 is resolved.
-// expectAssignable<FastifyInstance>(fastify().register(function (instance, opts): Promise<void> { }))
-// expectAssignable<FastifyInstance>(fastify().register(async function (instance, opts) { }, () => { }))
-// expectAssignable<FastifyInstance>(fastify().register(async function (instance, opts) { }, { logLevel: 'info', prefix: 'foobar' }))
+expectAssignable<FastifyInstance>(fastify().register(function (instance, opts): Promise<void> { return Promise.resolve() }))
+expectAssignable<FastifyInstance>(fastify().register(async function (instance, opts) { }, () => { }))
+expectAssignable<FastifyInstance>(fastify().register(async function (instance, opts) { }, { logLevel: 'info', prefix: 'foobar' }))
 
 expectError(fastify().register(function (instance, opts, next) { }, { logLevel: '' })) // must use a valid logLevel
 
diff --git a/types/register.d.ts b/types/register.d.ts
index 5eda7bd..664eca9 100644
--- a/types/register.d.ts
+++ b/types/register.d.ts
@@ -1,4 +1,4 @@
-import { FastifyPlugin, FastifyPluginOptions } from './plugin'
+import { FastifyPlugin, FastifyPluginCallback, FastifyPluginAsync, FastifyPluginOptions } from './plugin'
 import { LogLevel } from './logger'
 
 /**
@@ -6,11 +6,21 @@ import { LogLevel } from './logger'
  *
  * Function for adding a plugin to fastify. The options are inferred from the passed in FastifyPlugin parameter.
  */
-export interface FastifyRegister<T = void> {
+export type FastifyRegister<T = void> = {
   <Options extends FastifyPluginOptions>(
     plugin: FastifyPlugin<Options>,
     opts?: FastifyRegisterOptions<Options>
-  ): T;
+  ): T
+} & {
+  <Options extends FastifyPluginOptions>(
+      plugin: FastifyPluginCallback<Options>,
+      opts?: FastifyRegisterOptions<Options>
+  ): T
+} & {
+  <Options extends FastifyPluginOptions>(
+    plugin: FastifyPluginAsync<Options>,
+    opts?: FastifyRegisterOptions<Options>
+  ): T
 }
 
 export type FastifyRegisterOptions<Options> = (RegisterOptions & Options) | (() => RegisterOptions & Options)

results in

  test/types/plugin.test-d.ts:43:63
  ✖  43:63  Parameter instance implicitly has an any type.
  ✖  43:73  Parameter opts implicitly has an any type.
  ✖  44:69  Parameter instance implicitly has an any type.
  ✖  44:79  Parameter opts implicitly has an any type.
  ✖  45:69  Parameter instance implicitly has an any type.
  ✖  45:79  Parameter opts implicitly has an any type.

  6 errors

(where lines 43-45 are uncommented test lines above)


If the union is used in FastifyRegister<T = void> type then none of the overloads are resolved properly

  test/types/plugin.test-d.ts:26:22
  ✖  26:0   Expected an error, but found none.                                                                                                                                                                                                
  ✖  26:22  This expression is not callable.
  Each member of the union type FastifyRegister<FastifyInstance<Server, IncomingMessage, ServerResponse, FastifyLoggerInstance> & PromiseLike<...>> has signatures, but none of those signatures are compatible with each other.
  ✖  27:0   Expected an error, but found none.                                                                                                                                                                                                
  ✖  27:22  This expression is not callable.
  Each member of the union type FastifyRegister<FastifyInstance<Server, IncomingMessage, ServerResponse, FastifyLoggerInstance> & PromiseLike<...>> has signatures, but none of those signatures are compatible with each other.
  ✖  29:44  This expression is not callable.
  Each member of the union type FastifyRegister<FastifyInstance<Server, IncomingMessage, ServerResponse, FastifyLoggerInstance> & PromiseLike<...>> has signatures, but none of those signatures are compatible with each other.
  ✖  30:44  This expression is not callable.
  Each member of the union type FastifyRegister<FastifyInstance<Server, IncomingMessage, ServerResponse, FastifyLoggerInstance> & PromiseLike<...>> has signatures, but none of those signatures are compatible with each other.
  ✖  32:44  This expression is not callable.
  Each member of the union type FastifyRegister<FastifyInstance<Server, IncomingMessage, ServerResponse, FastifyLoggerInstance> & PromiseLike<...>> has signatures, but none of those signatures are compatible with each other.
  ✖  32:63  Parameter instance implicitly has an any type.
...

Though since that issue is resolved looks like the types are indeed wrong in some way. I currently don't have time to experiment with this but feel free to just push to this branch if you have more ideas.

@Ethan-Arrowood
Copy link
Member

@lundibundi I have a commit ready to go can you make sure to enable maintainer access to push to your fork?

@Ethan-Arrowood
Copy link
Member

Here is the git diff of my solution in case that is easier

diff --git a/fastify.d.ts b/fastify.d.ts
index 65c8a5b..26cdfdb 100644
--- a/fastify.d.ts
+++ b/fastify.d.ts
@@ -119,7 +119,7 @@ type TrustProxyFunction = (address: string, hop: number) => boolean
 /* Export all additional types */
 export { FastifyRequest, RequestGenericInterface } from './types/request'
 export { FastifyReply } from './types/reply'
-export { FastifyPlugin, FastifyPluginOptions } from './types/plugin'
+export { FastifyPluginCallback, FastifyPluginAsync, FastifyPluginOptions } from './types/plugin'
 export { FastifyInstance } from './types/instance'
 export { FastifyLoggerOptions, FastifyLoggerInstance, FastifyLogFn, LogLevel } from './types/logger'
 export { FastifyContext } from './types/context'
diff --git a/test/types/plugin.test-d.ts b/test/types/plugin.test-d.ts
index b8c7f04..1cf5de0 100644
--- a/test/types/plugin.test-d.ts
+++ b/test/types/plugin.test-d.ts
@@ -1,27 +1,17 @@
-import fastify, {
-  FastifyPlugin,
-  FastifyInstance,
-  FastifyPluginOptions,
-  RawServerBase, RawRequestDefaultExpression, RawReplyDefaultExpression
-} from '../../fastify'
+import fastify, { FastifyInstance, FastifyPluginOptions } from '../../fastify'
 import * as http from 'http'
 import * as https from 'https'
 import { expectType, expectError, expectAssignable } from 'tsd'
-import {FastifyPluginAsync, FastifyPluginCallback} from "../../types/plugin";
+import { FastifyPluginCallback, FastifyPluginAsync } from '../../types/plugin'
 
 // FastifyPlugin & FastifyRegister
 interface TestOptions extends FastifyPluginOptions {
   option1: string;
   option2: boolean;
 }
-const testPluginOpts: FastifyPlugin<TestOptions> = function (instance, opts, next) { }
+const testPluginOpts: FastifyPluginCallback<TestOptions> = function (instance, opts, next) { }
 
-
-// TODO: Remove explicit types when https://github.com/microsoft/TypeScript/issues/32571 is resolved.
-const testPluginOptsAsync: FastifyPlugin<TestOptions> = async function (
-  instance: FastifyInstance<RawServerBase, RawRequestDefaultExpression<RawServerBase>, RawReplyDefaultExpression<RawServerBase>>,
-  opts: TestOptions
-) { }
+const testPluginOptsAsync: FastifyPluginAsync<TestOptions> = async function (instance, opts) { }
 
 expectError(fastify().register(testPluginOpts, {})) // error because missing required options from generic declaration
 expectError(fastify().register(testPluginOptsAsync, {})) // error because missing required options from generic declaration
@@ -39,10 +29,9 @@ expectAssignable<FastifyInstance>(fastify().register(testPluginCallback, {}))
 const testPluginAsync: FastifyPluginAsync = async function (instance, opts) { }
 expectAssignable<FastifyInstance>(fastify().register(testPluginAsync, {}))
 
-// TODO: Uncomment when https://github.com/microsoft/TypeScript/issues/32571 is resolved.
-// expectAssignable<FastifyInstance>(fastify().register(function (instance, opts): Promise<void> { }))
-// expectAssignable<FastifyInstance>(fastify().register(async function (instance, opts) { }, () => { }))
-// expectAssignable<FastifyInstance>(fastify().register(async function (instance, opts) { }, { logLevel: 'info', prefix: 'foobar' }))
+expectAssignable<FastifyInstance>(fastify().register(function (instance, opts): Promise<void> { return Promise.resolve() }))
+expectAssignable<FastifyInstance>(fastify().register(async function (instance, opts) { }, () => { }))
+expectAssignable<FastifyInstance>(fastify().register(async function (instance, opts) { }, { logLevel: 'info', prefix: 'foobar' }))
 
 expectError(fastify().register(function (instance, opts, next) { }, { logLevel: '' })) // must use a valid logLevel
 
diff --git a/types/plugin.d.ts b/types/plugin.d.ts
index c9daa5d..afae888 100644
--- a/types/plugin.d.ts
+++ b/types/plugin.d.ts
@@ -1,30 +1,30 @@
-import { FastifyError } from 'fastify-error'
 import { FastifyInstance } from './instance'
 import {
   RawServerBase,
-  RawServerDefault,
   RawRequestDefaultExpression,
   RawReplyDefaultExpression
 } from './utils'
 
+/**
+ * FastifyPluginCallback
+ *
+ * Fastify allows the user to extend its functionalities with plugins. A plugin can be a set of routes, a server decorator or whatever. To activate plugins, use the `fastify.register()` method.
+ */
 export type FastifyPluginCallback<Options extends FastifyPluginOptions = {}> = (
   instance: FastifyInstance<RawServerBase, RawRequestDefaultExpression<RawServerBase>, RawReplyDefaultExpression<RawServerBase>>,
   opts: Options,
-  next: (err?: FastifyError) => void
+  next: (err?: Error) => void
 ) => void
 
-export type FastifyPluginAsync<Options extends FastifyPluginOptions = {}> = (
-  instance: FastifyInstance<RawServerBase, RawRequestDefaultExpression<RawServerBase>, RawReplyDefaultExpression<RawServerBase>>,
-  opts: Options
-) => Promise<void>;
-
 /**
- * FastifyPlugin
+ * FastifyPluginAsync
  *
  * Fastify allows the user to extend its functionalities with plugins. A plugin can be a set of routes, a server decorator or whatever. To activate plugins, use the `fastify.register()` method.
  */
-export type FastifyPlugin<Options extends FastifyPluginOptions = {}> =
-  FastifyPluginCallback<Options> | FastifyPluginAsync<Options>
+export type FastifyPluginAsync<Options extends FastifyPluginOptions = {}> = (
+  instance: FastifyInstance<RawServerBase, RawRequestDefaultExpression<RawServerBase>, RawReplyDefaultExpression<RawServerBase>>,
+  opts: Options
+) => Promise<void>;
 
 export interface FastifyPluginOptions {
   [key: string]: any;
diff --git a/types/register.d.ts b/types/register.d.ts
index 5eda7bd..d24ca00 100644
--- a/types/register.d.ts
+++ b/types/register.d.ts
@@ -1,4 +1,4 @@
-import { FastifyPlugin, FastifyPluginOptions } from './plugin'
+import { FastifyPluginOptions, FastifyPluginCallback, FastifyPluginAsync } from './plugin'
 import { LogLevel } from './logger'
 
 /**
@@ -8,7 +8,15 @@ import { LogLevel } from './logger'
  */
 export interface FastifyRegister<T = void> {
   <Options extends FastifyPluginOptions>(
-    plugin: FastifyPlugin<Options>,
+    plugin: FastifyPluginCallback<Options>,
+    opts?: FastifyRegisterOptions<Options>
+  ): T;
+  <Options extends FastifyPluginOptions>(
+    plugin: FastifyPluginAsync<Options>,
+    opts?: FastifyRegisterOptions<Options>
+  ): T;
+  <Options extends FastifyPluginOptions>(
+    plugin: FastifyPluginCallback<Options> | FastifyPluginAsync<Options>,
     opts?: FastifyRegisterOptions<Options>
   ): T;
 }

@lundibundi
Copy link
Contributor Author

lundibundi commented Jul 2, 2020

It should already be enabled
Screenshot from 2020-07-02 17-22-42
though I also added you as a collaborator to my fork just in case.

Edit: didn't think about overload syntax in interface. Would be great if this works, thanks for the help.

@Ethan-Arrowood
Copy link
Member

Awesome thank you! Rebased to hopefully fix CI

Copy link
Member

@Ethan-Arrowood Ethan-Arrowood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think my approval actually counts anymore but I think my previous request for changes blocks it so 🤷‍♀️

@Ethan-Arrowood
Copy link
Member

This seems to be the failing line of the CI: https://github.com/fastify/fastify/pull/2350/checks?check_run_id=831281965#step:6:8030

Not sure why, everything runs locally and I rebased on master

next: (err?: FastifyError) => void
): void;
}
export type FastifyPluginCallback<Options extends FastifyPluginOptions = {}> = (
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think such definition will break libraries such as fastify-autoload which rely upon existence of unified FastifyPlugin type (https://github.com/fastify/fastify-autoload/blob/master/fastify-autoload.d.ts)
I guess they will have to also use overload if there is no other way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So all the plugins types would need to be updated again? :/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a few options:

  • see if the union or intersection type will satisfy existing plugins
  • fix all plugins again (☹️)
  • add an alias for FastifyPlugin = FastifyPluginCallback as this is what it was before the change; mark as deprecated and then expect that update in v4

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's go with the 3rd route.

Copy link
Contributor Author

@lundibundi lundibundi Jul 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't union plugin type work out just fine for plugins, everything will work as it was but it will allow passing explicitly typed async functions to plugins (it just won't support type inference for async functions)?
(with marking this union type deprecated right away)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure off the top of my head but please try it out

@mcollina
Copy link
Member

mcollina commented Jul 9, 2020

there are conflicts and tests seems to fail

@Ethan-Arrowood
Copy link
Member

@lundibundi i know you are low on time so let me know if you'd like for me to continue to complete this pr!

Two things need to happen:

  • rebase and fix conflicts
  • settle the union or aliasing to not break current plugins

@lundibundi
Copy link
Contributor Author

lundibundi commented Jul 9, 2020

Done.

Tested the FastifyPlugin with fastify-autoload and everything looked fine, current functions with callback infer types just fine with FastifyPlugin.

Also tested fastify-plugin which actually broke (for async version) but I'm not sure how was it working before. Current types of fastify-plugin actually use non-existing promise overload of FastifyPlugin and don't cause a type error.
https://github.com/fastify/fastify-plugin/blob/af5b40ca492366e31999b2159a57510f48c96ca0/plugin.test-d.ts#L25
IMO this looks like a bug in fastify-plugin types and shouldn't be a blocker for this.

Can someone recommend other plugins that may be most affected by this change to check?

@mcollina
Copy link
Member

There is a conflict here.

Co-authored-by: Ethan Arrowood <ethan.arrowood@gmail.com>
@lundibundi
Copy link
Contributor Author

@mcollina done, I thought I rebased 🤷

@mcollina
Copy link
Member

@Ethan-Arrowood wdyt?

Copy link
Member

@Ethan-Arrowood Ethan-Arrowood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Great job on this! Thank you very much for contributing 😄

@github-actions
Copy link

github-actions bot commented Feb 9, 2022

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
typescript TypeScript related v3.x Issue or pr related to Fastify v3
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants