svsool / axios-better-stacktrace Goto Github PK

View Code? Open in Web Editor NEW

45.0 3.0 5.0 200 KB

Axios plugin that provides better stack traces for axios errors

Home Page: https://www.npmjs.com/package/axios-better-stacktrace

License: MIT License

JavaScript 3.96% TypeScript 96.04%

axios-plugin axios stacktrace error-handling

axios-better-stacktrace's People

Contributors

Stargazers

Watchers

Forkers

nowadays benhason1 conner1reimers abimaelmartell forivall

axios-better-stacktrace's Issues

ESM default export + CommonJS transpilation

Hi, it's me again;

I may have spoken too soon when I said it wasn't a deal breaker 😬

In a node ESM project, if Jest is used as the test framework, you need to transpile the code to CommonJS because Jest doesn't support Esm as of now.

But due to the fact that the exported function is imported as a default property of the imported object, once you transpile the code it ends up like this:

Which of course doesn't work. Since I've never used Typescript I don't know how to setup the compiler to export the function as default and not as a default property of the imported object.

My best bet is that you know how to fix this 😂

Stack traces in server-side requests (such as Nuxt.js)

tl;dr:

Nuxt.js uses Axios for its http request library.
Because Nuxt is partially server-side, Axios ends up making requests from the server context.
When a server-side Axios request fails and isn't otherwise caught/handled, the back trace reported in the log is very unhelpful in locating what file/request was responsible.
This package's purpose is solving exactly that, but isn't quite perfect in this specific situation.

Okay, how is `axios-better-stacktrace` involved?

It isn't, directly. I found this package while looking for solutions to the above problem and wanted to try it in the server-side context.

⚠️ This is not directly Axios's problem, Nuxt's problem, or even this package's problem. ...there's just no better place to capture this for Google to find and help other people.

Reproduction repo

See here: beporter/axios-better-stacktrace-nuxt-repro@1823a33

That's a create-nuxt-app boilerplate, with minimal modifications made to demonstrate the problem.

Copying the instructions here:

git clone https://github.com/beporter/axios-better-stacktrace-nuxt-repro.git && cd axios-better-stacktrace-nuxt-repro
npm i
npm run dev
Visit http://localhost:3000
- The terminal running npm run dev will show the backtrace (including the Error: Axios Better Stacktrace section), and the trace will include pages/index but it's buried a bit.
- The browser will report "Maximum call stack size exceeded."

Example error output

This is for a server-side request, made from a Nuxt "page" that uses a fetch() call.

Console output

ℹ Waiting for file changes                                                                                                                                                                                                                                                                                        08:12:04
ℹ Memory usage: 161 MB (RSS: 263 MB)                                                                                                                                                                                                                                                                              08:12:04
ℹ Listening on: http://localhost:3000/                                                                                                                                                                                                                                                                            08:12:04

 ERROR  Error in fetch(): Request failed with status code 400                                                                                                                                                                                                                                                     08:12:12

  at createError (node_modules/axios/lib/core/createError.js:16:15)
  at settle (node_modules/axios/lib/core/settle.js:17:12)
  at IncomingMessage.handleStreamEnd (node_modules/axios/lib/adapters/http.js:260:11)
  at IncomingMessage.emit (events.js:203:15)
  at endReadableNT (_stream_readable.js:1145:12)
  at process._tickCallback (internal/process/next_tick.js:63:19)
  Error: Axios Better Stacktrace
  at Function.axiosBetterStacktraceMethodProxy [as get] (node_modules/axios-better-stacktrace/lib/cjs/axiosBetterStacktrace.js:84:110)
  at Function.module.exports../.nuxt/axios.js.axiosExtra.(anonymous function) (server.js:394:25)
  
  at VueComponent.fetch (pages/index.js:27:42)      // <--- This right here is what people are going to care about.

  at VueComponent.serverPrefetch (server.js:1485:31)
  at waitForServerPrefetch (node_modules/vue-server-renderer/build.dev.js:8305:34)
  at renderComponentInner (node_modules/vue-server-renderer/build.dev.js:8455:3)
  at renderComponent (node_modules/vue-server-renderer/build.dev.js:8412:5)
  at renderNode (node_modules/vue-server-renderer/build.dev.js:8323:5)
  at resolve (node_modules/vue-server-renderer/build.dev.js:8450:5)
  at waitForServerPrefetch (node_modules/vue-server-renderer/build.dev.js:8316:3)
  at renderComponentInner (node_modules/vue-server-renderer/build.dev.js:8455:3)
  at renderComponent (node_modules/vue-server-renderer/build.dev.js:8412:5)
  at renderNode (node_modules/vue-server-renderer/build.dev.js:8323:5)
  at resolve (node_modules/vue-server-renderer/build.dev.js:8450:5)
  at waitForServerPrefetch (node_modules/vue-server-renderer/build.dev.js:8316:3)
  at renderComponentInner (node_modules/vue-server-renderer/build.dev.js:8455:3)

Browser Screenshot

What's the point here, buster?

This has been driving my team bonkers for months, and I wanted people to see what the best possible option is (as of this writing). If there's a way to improve axios, or nuxt, or this package, I'd love to help, but the first step was to document it and start the discussion.

Thanks for your time! 🙇

Module exports a default property, typescript compiler config issue ?

Hi,

When importing this module in a node ESM environment the function exported is exported as default, which is not what you intended, cf: the readme.

Unable to resolve dependency tree

What did I do:

npm i axios
npm i axios-better-stacktrace

Got an error (from report.txt which on screenshot):

Updated:

With --legacy-peer-deps option to npm install library is installed without above error.

Updated 1:

When I install 2 dependencies at once, then no errors occur.
npm i axios axios-better-stacktrace

Add an option to remove the original axios stack

I see no point in including the original axios stack since It's borderline useless.

My suggestion is to add an option that transforms this:

Error: Request failed with status code 404
    at createError (./node_modules/axios/lib/core/createError.js:16:15)
    at settle (./node_modules/axios/lib/core/settle.js:17:12)
    at IncomingMessage.handleStreamEnd (./node_modules/axios/lib/adapters/http.js:244:11)
    at IncomingMessage.emit (node:events:388:22)
    at IncomingMessage.EventEmitter.emit (node:domain:470:12)
    at endReadableNT (node:internal/streams/readable:1294:12)
    at processTicksAndRejections (node:internal/process/task_queues:80:21)
Error: Axios Better Stacktrace
    at Function.axiosBetterStacktraceMethodProxy [as get] (./src/axiosBetterStacktrace.ts:167:15)
    at getNpmPage (./demo/index.ts:10:35) <---- this is what usually useful to know for further debugging and this plugin adds 🙂
    at ./demo/index.ts:13:9
    at step (./demo/index.ts:33:23)
    at Object.next (./demo/index.ts:14:53)
    at ./demo/index.ts:8:71
    at new Promise (<anonymous>)
    at __awaiter (./demo/index.ts:4:12)
    at ./demo/index.ts:12:2
    at Object.<anonymous> (./demo/index.ts:16:3)

into this

Error: Request failed with status code 404
    at Function.axiosBetterStacktraceMethodProxy [as get] (./src/axiosBetterStacktrace.ts:167:15)
    at getNpmPage (./demo/index.ts:10:35) <---- this is what usually useful to know for further debugging and this plugin adds 🙂
    at ./demo/index.ts:13:9
    at step (./demo/index.ts:33:23)
    at Object.next (./demo/index.ts:14:53)
    at ./demo/index.ts:8:71
    at new Promise (<anonymous>)
    at __awaiter (./demo/index.ts:4:12)
    at ./demo/index.ts:12:2
    at Object.<anonymous> (./demo/index.ts:16:3)

Improving axios error detection

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch [email protected] for the project I'm working on.

Inside a typescript project the net.js library don't always throw error as instances or errors.
The instanceof keyword can failed during the check.

Here is the diff that solved my problem:

diff --git a/node_modules/axios-better-stacktrace/lib/axiosBetterStacktrace.js b/node_modules/axios-better-stacktrace/lib/axiosBetterStacktrace.js
index f16af8e..91678fd 100644
--- a/node_modules/axios-better-stacktrace/lib/axiosBetterStacktrace.js
+++ b/node_modules/axios-better-stacktrace/lib/axiosBetterStacktrace.js
@@ -12,8 +12,11 @@ var __assign = (this && this.__assign) || function () {
 };
 Object.defineProperty(exports, "__esModule", { value: true });
 var patchedSym = Symbol('axiosBetterStacktrace.patched');
+var isError = function (error) {
+  return Object.prototype.toString.call(error) === "[object Error]";
+}
 var isAxiosError = function (error) {
-    return error instanceof Error && error.isAxiosError;
+    return (error instanceof Error || isError(error)) && error.isAxiosError;
 };
 var axiosMethods = [
     'request',

This issue body was partially generated by patch-package.

ESM dist doesn't have .d.ts file exported

The CJS dist has the .d.ts types file exported, but the ESM one doesn't, causing typescript to think that there are no types for this package

The caught error stack is modified after interceptors

Hi, thanks for the great lib! One issue I've found is that other interceptors which you attach to your Axios instance runs before the patched code catches the error. This is by design, but it means we do not get the modified stack trace in our interceptors.

We're using an error-interceptor to handle logging across different API calls. Would there be some way to attach the "top most error" to the request config object, so we can resolve it in the interceptor by way of error.config.topmostError or something?

broken error detection

Hi! First of all, thank you for maintaining this, it's very much appreciated!

I just want to report that #5 broke the error enhancement for us.
When using a custom interceptor for debugging the error object, I have the following:

console.log(Object.prototype.toString.call(error));
> [object Object]
console.log(error instanceof Error);
> true

So using a string like [object Error] to detect error objects is probably not the way to go.
FYI I have nodejs v16.17.0

Going back to v2.1.0 fixed it for us.
Let me know if I can bring any more helpful info.
Cheers! ✌️