-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
build(deps): revert to peerDependency, refer to #73 #78
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should mention in the docs users should now install @synclair/typebox
by themselves.
@RafaelGSS i updated the readme for it |
PTAL @mcollina |
@RafaelGSS would you mind to help check my approach for @mcollina testing concerns mentioned in #63 , I tried extending the testing workflow to perform cross peer dependency versions testing that would ease the need to specify wider version of Typebox for example ^0.26.0 https://github.com/nadhifikbarw/fastify-type-provider-typebox/tree/next The downside is having test job numbers increase exponentially the wider the test range is for obv reason, but otherwise it's simplest approach i could think of. Example tests run If this is okay i can also merge to PR branch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm.
The question on the CI comes if we want to support multiple versions of typebox outside of the current range. In that case, we need to run the tests for each one of those.
I will keep CI changes to perform multi version test in my fork next branch, if we do ended up want to support it, I can make another PR ( ping is welcomed ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Could you send that follow-up PR? |
@nadhifikbarw @mcollina probably we should revert something more, since |
@rvitaliy reversion work to peer is light, but we keep oscillating on this back and forth, might be great to have final decision from maintainers on this first before doing it. |
That is correct. All package managers now install peerDeps in a way that enable that. |
Checklist
npm run test
andnpm run benchmark
and the Code of conduct
This is peerDependency revert fix version mentioned for #73