Debugging Typescript without proper tools, in a nutshell. The original file might have 72 lines, but the transpiled JS file it’s debugging is like 3 times that many
Honestly, you don’t want production to tell users what your exact errors are, and especially not what the source code looks like and where to find the problem exactly.
Production errors should mostly go “Well, this was on (y)our side, sorry about that” and nothing more.
If it’s in the minified front end code it’s already client side, of course you don’t show it to the user but they could find out if they wanted to. Server side errors are where you really have to watch out not to give out any details, but then logging them is also easier since it’s already on the server.
Debugging Typescript without proper tools, in a nutshell. The original file might have 72 lines, but the transpiled JS file it’s debugging is like 3 times that many
That when the file isn’t minified, no shit it’s on line 1 there is only one line
Production errors at their finest
Honestly, you don’t want production to tell users what your exact errors are, and especially not what the source code looks like and where to find the problem exactly.
Production errors should mostly go “Well, this was on (y)our side, sorry about that” and nothing more.
If it’s in the minified front end code it’s already client side, of course you don’t show it to the user but they could find out if they wanted to. Server side errors are where you really have to watch out not to give out any details, but then logging them is also easier since it’s already on the server.
Ah you’re right, I’m thinking too much like a backend dev!
No, not all error have security implications
Not only that, but with JS you by definition have no code obfuscation. Minifying it just saves some bandwidth
Yeah, if one really wants obfuscation for JS, then it requires an extra build step. E.g. this: JavaScript-obfuscator
Enable sourcemaps