-
Notifications
You must be signed in to change notification settings - Fork 8
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
Up front interceptor config #25
base: master
Are you sure you want to change the base?
Conversation
… name and options injection token name for easier deugging
8c5ac5a
to
950771f
Compare
Just added a workflow to run tests against the three node versions that are receiving updates currently. You can see an example of what it will look like on this test PR here: keawade#1 Example run: https://github.com/keawade/nestjs-http-promise/actions/runs/11673157112?pr=1 |
Trying to fix issue installing in new NestJS project created with `nest new`
Hey @benhason1 👋. Bumping this in the hopes it could get some discussion or maybe even a merge. 😄 |
Hi @keawade thanks for the PR, I will look at it in the coming days |
Howdy @benhason1, I've been happily using this library in my work for a while now. Thanks!
In my work I've found myself needing to configure Axios interceptors up front but not finding a good way to do that between NestJS's constraints and the current implementation of this module. This PR aims to provide a way for users to configure Axios interceptors via the Module registration.
To do this, this PR introduces a breaking change to how the module is configured. The module options object is no longer the Axios configuration object but rather a module options object of
I'm not a huge fan of breaking changes but I found myself preferring this approach to overloading the existing configuration object. Since I was splitting something out from the shared Axios and Axios Retry config object anyways I figured it might be worth additionally explicitly disentangling those two configuration objects as well which should have the additional benefit of lowering the risk of name collisions between the two libraries.
I refactored the module to use NestJS's
ConfigurableModuleBuilder
make it much simpler for me to add the new module configuration options.This should also mean you won't have to maintain your own implementations of
.register
and.registerAsync
any more as that is now handed off to NestJS's builder.I kept the bulk of these changes in the first commit to help make it easier to review.
To make sure I didn't break anything unexpected I added tests of the module construction. I used
vitest
as it is one of the most Just Works TM solutions I'm aware of.It appeared the documented "better axios stack trace" is no longer implemented by this library directly so I removed references to it in the documentation. As far as I can tell the related issues in the Axios repo have been resolved and improvements to the stack trace have been merged.
Let me know if you have any questions or suggestions for how to improve this PR! Thanks again!