Feature/v11

[ecyrbe]

• Any validation library support, native support for Zod / Io-Ts :
  • By using the TypeProvider pattern we can now make zodios validation agnostic.
  • Implement at least ZodTypeProvider and IoTsTypeProvider since they both support input and output type inferrence
  • openapi generation will only be compatible with zod though
  • Not a breaking change so no codemod needed
• const in generics:
  • migrate to typescript 5.0
  • will allow to get rid of Narrow helper that is slow and may prevent zodios to really be agnostic to validation library
  • should improve perf
  • will maintain v10 for some more time to let users migrate
  • need to provide a big warning about ts dependency
• Plugins:
  • implement new plugin system that allows to match endpoints with more advance rules
  • allow to match endpoint with regex
  • allow to match endpoint with custom function
  • allow to control the priority of the plugin (low, normal, high) => two plugins with same priority will be executed in the order of declaration
• MonoRepo:
  • Zodios will become a really large project so maybe migrate to turbo repo + pnpm
  • not a breaking change
• Transform:
  • By default, activate transforms on backend and disable on frontend (today it's the opposite), would make server transform code simpler since with this option we could make any transforms activated not just zod defaults.
  • Rationale being that transformation can be viewed as business code that should be kept on backend
  • breaking change => codemod to keep current defaults by setting them explicitly
• Axios:
  • Move Axios client to it's own package @zodios/axios and keep @zodios/core with only common types and helpers
  • Move plugins to @zodios/axios-plugins
  • breaking change => easy to do a codemod for this
• Fetch:
  • Create a new Fetch client with almost the same features as axios, but without axios dependency @zodios/fetch
  • Today we have fetch support with a plugin for axios instance (zodios maintains it's own axios network adapter for fetch). But since axios interceptors are not used by zodios plugins, we can make fetch implementation lighter than axios instance.
  • Create plugins package @zodios/fetch-plugins
  • Not sure it's doable without a lot of effort to keep it in sync/compatible with axios client
  • new feature, so no codemod needed
• React/Solid:
  • make ZodiosHooks independant of Zodios client instance (axios, fetch)
  • not a breaking change, so no codemod needed
• Client Request Config
  • uniform Query/Mutation with body sent on the config and not as a standalone object. This would allow to not do client.deleteUser(undefined, { params: { id: 1 } }) but simply client.deleteUser({ params: { id: 1 } })
  • breaking change, so a codemod would be needed, but might be difficult to implement
• Mock/Tests:
  • if we implement an abstraction layer for client instance, relying on moxios to mock APIs response will likely not work for fetch implementation.
  • create a @zodios/testing package that work for both axios/fetch clients
  • new feature, so no breaking change (no codemod needed)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ecyrbe]

Ping

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[toteto]

@ecyrbe any change on getting the v11 out soon? Maybe new beta release? I am facing a issue with the beta19 method isErrorFromAlias, it is not comparing the error path to the enpoint path correctly. It is being fixed in the latest state of the branch and also it is OK on main.