How are the types not totally screwed up in this kind of pattern? I get that this is JS, but since most of us at the level to be reading this post actually write TS, isn't it true that most of those transformations actually modify the type of the object, and therefor each would need to have a slightly different intermediary type?
When I actually have this problem, I usually define the input as an interface and the output as another interface(maybe extending the input interface).
Then I write a SINGLE function that calls those other functions, collects the data into variables, and then builds a new object of the new data type, and then returns that.
You're right. Nobody bothers to make scanners because there's no data, and nobody has come up with a good format to convey the data between producers (like NVD) and consumers (like dependabot).
It truly is a chicken and egg problem. There are next to no automated scanners that make use of data like that, semgrep is the furthest along and my company is close behind them at taking a stab at it as far as I can tell. Heck there are hardly any that do anything with the existing "Environmental" part of the CVSS, and that has been pretty well populated by NVD, I believe.
The existing interchange formats for vulnerability data, such as OSV, are underdesigned to the point that it feels like GitHub CoPilot designed them. It's real work to even get to the point that you can consume them, given all the weird choices in there. Sorry if I'm salty.
There is an attempt to create a standard for situational vulnerability exposure called "VEX" or Vulnerability Exchange Format, but it's almost entirely focused on conveying information about what vulnerabilities have been manually eliminated, so that software "vendors" can satisfy their customers, especially in government contracts. It's not modeling the full picture of what can happen in a dependency tree and all the useful false-positive information in there.
I actually found out a bit more about it and added it to the blog post. I found links to the macro examples and so on, added it. It uses jsx/tsx with special tags like <string> and <array>. Honestly, that strikes me as completely genius. I really hope it can emit types before the typescript compilation step, not sure. Tried to read the zig but...it's deep.
I'd REALLY like to hear more about the macro system. I've been yelling about wanting that to become part of typescript for a long time, but I don't think they quite have the vision.
In Zig, code can run at compile time, and thats amazing. That's one of the main things I want in TypeScript. Once you have that, everything from type reflection to native graphql types without codegen is just a library away.
Yeah, I'd really, really like to hear more about that if you can point me at anything. Overall, all of the decisions Bun is making, in just about every part of the ecosystem it touches, are things that I have been really excited about. I've got a good feeling about this and I'm trying to scrape some time together to help out.
As for esbuild, I don't think you're correcting the article because it said that the parser is a `port` of esbuild, not "based on". You're probably just replying to the other comment :)
When I actually have this problem, I usually define the input as an interface and the output as another interface(maybe extending the input interface).
Then I write a SINGLE function that calls those other functions, collects the data into variables, and then builds a new object of the new data type, and then returns that.
Maybe I'm missing the point here.