tslog icon indicating copy to clipboard operation
tslog copied to clipboard

Feature Request: Show correct log position when running in vite

Open koljada opened this issue 1 year ago • 6 comments

I'm developing vue 3 application using vite. tslog library is useful for me but unfortunately, I cannot make it showing correct log positions. I tried to set source maps in vite.config.ts and tsconfig.json but it didn't work. My log position always looks like this: /node_modules/.vite/deps/tslog.js:937

Did I miss come configuration step or it is not supported yet?

koljada avatar Sep 12 '24 11:09 koljada

After some investigation I found that stackDepthLevel value is wrong, at least when running with vite on my machine. In my case it's needed to use 6 instead of 5. Here is one of my stack frames:

    at getCallerStackFrame (http://localhost:5173/node_modules/.vite/deps/tslog.js?v=720e19ab:559:55)
    at Object.getMeta (http://localhost:5173/node_modules/.vite/deps/tslog.js?v=720e19ab:556:44)
    at Logger._addMetaToLogObj (http://localhost:5173/node_modules/.vite/deps/tslog.js?v=720e19ab:871:50)
    at Logger.log (http://localhost:5173/node_modules/.vite/deps/tslog.js?v=720e19ab:710:203)
    at Logger.trace (http://localhost:5173/node_modules/.vite/deps/tslog.js?v=720e19ab:938:18)
    at http://localhost:5173/src/composables/useWidget.ts:82:27
    at http://localhost:5173/node_modules/.vite/deps/chunk-IDN7BJ6T.js?v=720e19ab:4845:40
    at callWithErrorHandling (http://localhost:5173/node_modules/.vite/deps/chunk-IDN7BJ6T.js?v=720e19ab:2289:19)
    at callWithAsyncErrorHandling (http://localhost:5173/node_modules/.vite/deps/chunk-IDN7BJ6T.js?v=720e19ab:2296:17)
    at hook.__weh.hook.__weh (http://localhost:5173/node_modules/.vite/deps/chunk-IDN7BJ6T.js?v=720e19ab:4825:19)

So I fixed the problem by creating my custom logger class and passing 6 value to the base class

koljada avatar Sep 12 '24 18:09 koljada

That worked for me. My (ugly!) workaround:

class MyLogger<T> extends Logger<T> {
    constructor(settings?: ISettingsParam<T>, logObj?: T) {
        super(settings, logObj);
        // @ts-ignore setting this private member as a workaround for https://github.com/fullstack-build/tslog/issues/302
        this.stackDepthLevel = 6
    }
}

vivlim avatar Nov 11 '24 09:11 vivlim

Related issue when tslog is proxied by another logger: https://github.com/loglayer/loglayer/issues/257

Perhaps stackDepthLevel could be made public so subclassing isn't required? Or better yet findFirstExternalFrameIndex could be turned into an overridable hook?

kitschpatrol avatar Oct 06 '25 20:10 kitschpatrol

Which version are you on? Should’ve been fixed with the current release 4.10.0

terehov avatar Oct 06 '25 21:10 terehov

Hi thanks for the quick reply — I'm on 4.10.2.

This is definitely fixed for the general case by findFirstExternalFrameIndex, but there are still situations where overriding the stack index could be helpful.

In the case of using tslog with log proxies like LogLayer, the user's passing their own tslog instance into the proxy... but the call site ends up a few frames up from where findFirstExternalFrameIndex thinks it is.

The user can fix this manually with the subclassing strategy / private member hack shown above before the tslog instance is passed to LogLayer, but DX would be nicer if LogLayer could figure it out and fix the stack index on the tslog instance it's given. (There's some more discussion in the LogLayer issue previously linked for context.)

kitschpatrol avatar Oct 06 '25 21:10 kitschpatrol

I had a look at the code and maybe there's another, yet more flexible solution: You could offer a configuration property to add values to callerIgnorePatterns as defined in createLoggerEnvironment in BaseLogger.js. This way noone needs to fiddle with indices or write their own custom logic.

cnitschkowski-atos avatar Oct 09 '25 06:10 cnitschkowski-atos