Thanks for the tip! I’ll double check that when I get back to work next week.
I’ve written a lot of NodeJS apps in vanilla JS, and plenty of .NET backend stuff too. The transition to serious TS has been relatively recent. I like it alright, but dislike the added complexity that comes with all the various config files - vanilla JS has enough of that already!
I'm a former .NET dev ... I stopped quite a few years ago after I joined a Bay Area company. It was quite a change. React 1 was just coming out and I used to just write bad JS on my webpages and I had to rewrite our front-end in React. Also, ES5 or 6 or whatever was getting popular and we had to transition from CoffeeScript.
The JS world gave me whiplash after doing so many years of Enterprise .NET. The .NET tools felt so much more polished.
The fundamentals of Node to me were different than .NET. .NET felt like it had a lot more cruft and "magic" at first. With Node it felt deceptively simpler at first. Then when the require syntax was going away and we had imports but then it wasn't a real import. It was a TypeScript import or a webpack import that did a require behind the scenes. Then I had to understand why we used typescript but then what was the point of tsc vs babel vs webpack vs esbuild what their roles were and I kind got a bit obsessed with understanding what they did and what was happening under the hood. Then Node officially did do import and I had to understand what that was all about and how it affected our compilers or bundlers.
Sorry I rant pointlessly. Godspeed on your journey!
In this industry where we are all a little afraid to admit that we don’t know something, it’s nice to be reminded that everyone is always learning all the time and that there’s no way any of us can know everything.
I’m enjoying the learning process, despite its paper cuts, and love where I work. I enjoy TS itself but I do wish the process of setting up a new project/config stuff were more streamlined. Maybe in the future!
Btw, you probably already know this, but if you don't. The later versions of Node can run typescript natively. By "run", I mean, it can run a subset of the language, if your project indirectly or indirectly references a file that has "decorators" or something like that, then you'll need to use another compiler.
ts-node or tsx are runners that I use typically if I just want to "run" something. They're basically zero config runners and I can debug with them with VS Code.
Oh, they are included in the build. But I still get error messages that don’t actually point to the line in the TS source file sometimes.
Maybe I have something configured wrong - TS projects always include a more config files of different kinds than I see in other languages I work in - but it happens.
If it's only rarely, it might just be some dumb caching issue, or it can be a build ordering issue. Like you have to be careful in Rollup configs or some tasks will mangle the code before a sourcemap is generated. Otherwise iirc it may have to be turned on in browser settings, though hopefully they're on by default these days.
It's surprisingly good as a backend language, if you don't really need OOP all that much. The perfect case is probably using it in microservices that only really need to do a bit of data manipulation and some database interfacing.
I’ve had pretty good experiences with it even situations with moderate data manipulation. There are some tricks you can use to engage different phases of the event loop to keep the data processing from blocking too much.
It’s still not as good as Java/C#/Go, of course, but it can help get some more performance out of Node.
That happens all the time with Python. It often shows me errors in the imported modules, which are easily confused with my own code if I'm tired and don't read the message properly.
It can also happen in Python if you edit the file after runtime. It parses the code on import, but re-reads the file as text during the error message, so if you added or deleted lines, the error report can report a dubious line.
My first suspect is an incorrectly-terminated statement which looks like it should end on line 41. The compiler/interpreter probably read the newline and ticked over before uncovering the error, and didn't recover properly due to some edge case.
Depending on the language, this could be an issue where the line above is actually transpiled to be a line below due to inlining in some lambda function or similar.
45 Comments
KoboldCoterie@pawb.social · 94 pts · 214d
Plot twist: The code is written in Whitespace
MadMadBunny@lemmy.ca · 20 pts · 214d
FFS….
Taleya@aussie.zone · 6 pts · 214d
I hate whitespace so fucking much. Why must i deal with yaml professionally
anomnom@sh.itjust.works · 3 pts · 214d
All those closing brackets and commas in json suck too. And XML is a fucking waste of time. I’ll take writing yaml any day.
marlowe221@lemmy.world · 58 pts · 214d
This happens all the time with TypeScript. The transpiled JS that actually runs will naturally have different line numbers than the TS you wrote!
To be fair, the reported line number is usually close enough that I can find the issue without much trouble.
It’s not my favorite back end language, but it’s what everyone on my team knows…
folekaule@lemmy.world · 43 pts · 214d
This is what source maps are for. With the right tools you can debug the original source instead of the minified version.
lobut@lemmy.ca · 18 pts · 214d
Remember to add --enable-source-maps and as long as your tools are configured properly it should point to the right line!
marlowe221@lemmy.world · 9 pts · 214d
Thanks for the tip! I’ll double check that when I get back to work next week.
I’ve written a lot of NodeJS apps in vanilla JS, and plenty of .NET backend stuff too. The transition to serious TS has been relatively recent. I like it alright, but dislike the added complexity that comes with all the various config files - vanilla JS has enough of that already!
lobut@lemmy.ca · 5 pts · 214d
I'm a former .NET dev ... I stopped quite a few years ago after I joined a Bay Area company. It was quite a change. React 1 was just coming out and I used to just write bad JS on my webpages and I had to rewrite our front-end in React. Also, ES5 or 6 or whatever was getting popular and we had to transition from CoffeeScript.
The JS world gave me whiplash after doing so many years of Enterprise .NET. The .NET tools felt so much more polished.
The fundamentals of Node to me were different than .NET. .NET felt like it had a lot more cruft and "magic" at first. With Node it felt deceptively simpler at first. Then when the
requiresyntax was going away and we hadimportsbut then it wasn't a realimport. It was a TypeScriptimportor awebpackimport that did arequirebehind the scenes. Then I had to understand why we usedtypescriptbut then what was the point oftscvsbabelvswebpackvsesbuildwhat their roles were and I kind got a bit obsessed with understanding what they did and what was happening under the hood. Then Node officially did doimportand I had to understand what that was all about and how it affected our compilers or bundlers.Sorry I rant pointlessly. Godspeed on your journey!
marlowe221@lemmy.world · 5 pts · 214d
No worries on the ranting!
In this industry where we are all a little afraid to admit that we don’t know something, it’s nice to be reminded that everyone is always learning all the time and that there’s no way any of us can know everything.
I’m enjoying the learning process, despite its paper cuts, and love where I work. I enjoy TS itself but I do wish the process of setting up a new project/config stuff were more streamlined. Maybe in the future!
lobut@lemmy.ca · 2 pts · 213d
Yeah, absolutely agreed.
Btw, you probably already know this, but if you don't. The later versions of Node can run
typescriptnatively. By "run", I mean, it can run a subset of the language, if your project indirectly or indirectly references a file that has "decorators" or something like that, then you'll need to use another compiler.ts-nodeortsxare runners that I use typically if I just want to "run" something. They're basically zero config runners and I can debug with them with VS Code.marlowe221@lemmy.world · 3 pts · 213d
Yeah, I’ve read about the development of the ability to run TS natively in Node. It sounds really promising!
I’m not familiar with ts-node though. I’ll have to check that out.
marlowe221@lemmy.world · 3 pts · 214d
Well sure. But the error messages don’t point to those, which was what had me chuckling about this meme.
MotoAsh@piefed.social · 3 pts · 214d
They would point to the right lines if source maps were included in the build.
marlowe221@lemmy.world · 2 pts · 214d
Oh, they are included in the build. But I still get error messages that don’t actually point to the line in the TS source file sometimes.
Maybe I have something configured wrong - TS projects always include a more config files of different kinds than I see in other languages I work in - but it happens.
MotoAsh@piefed.social · 2 pts · 213d
If it's only rarely, it might just be some dumb caching issue, or it can be a build ordering issue. Like you have to be careful in Rollup configs or some tasks will mangle the code before a sourcemap is generated. Otherwise iirc it may have to be turned on in browser settings, though hopefully they're on by default these days.
BedSharkPal@lemmy.ca · 15 pts · 214d
Wait you said back end...
python@lemmy.world · 6 pts · 214d
It's surprisingly good as a backend language, if you don't really need OOP all that much. The perfect case is probably using it in microservices that only really need to do a bit of data manipulation and some database interfacing.
marlowe221@lemmy.world · 3 pts · 214d
I’ve had pretty good experiences with it even situations with moderate data manipulation. There are some tricks you can use to engage different phases of the event loop to keep the data processing from blocking too much.
It’s still not as good as Java/C#/Go, of course, but it can help get some more performance out of Node.
marlowe221@lemmy.world · 3 pts · 214d
You are familiar with NodeJS, yes? 👍
irelephant@lemmy.dbzer0.com · 2 pts · 214d
It's a really popular choice and has been for the few years.
kayzeekayzee@lemmy.blahaj.zone · 45 pts · 214d
When your #includes get flattened before compiling: "Error on line 1103" (file is 190 lines long)
flambonkscious@sh.itjust.works · 5 pts · 214d
Sounds like my time compiling autoit code. Fuck I hated that
hellfire103@lemmy.ca · 35 pts · 214d
That happens all the time with Python. It often shows me errors in the imported modules, which are easily confused with my own code if I'm tired and don't read the message properly.
eager_eagle@lemmy.world · 10 pts · 214d
how's that the same thing as in the picture?
CallMeAl@piefed.zip · 8 pts · 214d
it happens all the time in bash. i write some and there's no error but everyone complains that i didn't use brainfuck
diffaldo@lemmy.dbzer0.com · 4 pts · 214d
You dont like brainfuck!?😨
hellfire103@lemmy.ca · 8 pts · 214d
Here it is in greentext form:
eager_eagle@lemmy.world · 2 pts · 214d
Python stack traces give you all files involved in the error, with their lines. I don't know what you're talking about
irelephant@lemmy.dbzer0.com · 9 pts · 214d
hence the
ZoteTheMighty@lemmy.zip · 3 pts · 214d
It can also happen in Python if you edit the file after runtime. It parses the code on import, but re-reads the file as text during the error message, so if you added or deleted lines, the error report can report a dubious line.
billwashere@lemmy.world · 29 pts · 214d
It’s always a semicolon or parentheses.
Aedis@lemmy.world · 21 pts · 214d
This is why we have debug and release builds.
So that when actual clients tell us there's an error on line 42 we close the bug instantly as a no repro.
/s
mercano@lemmy.world · 19 pts · 214d
JS minification can make debugging much harder.
MotoAsh@piefed.social · 9 pts · 214d
Source maps are friends.
ThirdConsul@lemmy.zip · 6 pts · 214d
In the early 2010s there was a trend to throw in obfuscation into the minis.
Redkey@programming.dev · 18 pts · 214d
My first suspect is an incorrectly-terminated statement which looks like it should end on line 41. The compiler/interpreter probably read the newline and ticked over before uncovering the error, and didn't recover properly due to some edge case.
pentagon@lemmy.world · 13 pts · 213d
NichEherVielleicht@feddit.org · 9 pts · 213d
Exactly.
sga@piefed.social · 10 pts · 214d
rizzothesmall@sh.itjust.works · 10 pts · 214d
Curse you optimiser!
Only a good stack trace can save you now.
neukenindekeuken@sh.itjust.works · 7 pts · 214d
Depending on the language, this could be an issue where the line above is actually transpiled to be a line below due to inlining in some lambda function or similar.
Digit@lemmy.wtf · 5 pts · 214d
Best laugh of the day so far.
Laughed too loud, scared the wildlife outside.
PS, just gotta look at lines above. Maybe rainbow delimiters can help.
leds@feddit.dk · 3 pts · 212d
}
NichEherVielleicht@feddit.org · 1 pts · 212d
You scare me!
kionay@lemmy.world · 2 pts · 213d
I've had negative line number errors in an RPA program before. That one really caught me off guard.