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.

Maybe I'm missing the point here.

In what format is that information coming in? There are no function taints in githubs OSV data or NVD's data that I can see.

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).

I wrote a blog post talking about some of this stuff: https://www.lunasec.io/docs/blog/the-issue-with-vuln-scanner...

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.

Yeah agreed. When I see these problem statements, I see us addressing problems that are by-products of vulnerability fatigue.

I.e “be lazy and ignore those vulnerabilities by using our tools!”

It hardly solves the true issue of an industry wide challenge of lack of useful information or even transparency of said information from responsible parties. I believe this laziness is what got us here in the first place.

I think it's one of those things that if you haven't hit the wall with the JS ecosystem yet, you don't know the wall is there.

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 :)

Searching Bun's documentation (currently the long README on GitHub) for "macro", I only see a brief usage example as part of the build configuration, like:

  [macros]
  # Remap any import like this:
  #     import {graphql} from 'react-relay';
  # To:
  #     import {graphql} from 'macro:bun-macro-relay';
  react-relay = { "graphql" = "bun-macro-relay" }

..Or as a transpiler option:

  const transpiler = new Bun.Transpiler({
    loader: "tsx",
    define: {
      "process.env.NODE_ENV": JSON.stringify("development"),
      user_undefined: "undefined",
    },
    platform: "bun",
    macro: {
      inline: {
        whatDidIPass: `${import.meta.dir}/inline.macro.js`,
      },
      react: {
        bacon: `${import.meta.dir}/macro-check.js`,
      },
    },
  });

..But not within the transpiled code itself.

Ooh, hold on - there's more in /test/macro. Here's hello-fetch-macro.tsx.

  import { fetchSync } from "macro:./fetchSync.tsx";

  const synchronousFetch = fetchSync(`https://example.com`);

  console.log(synchronousFetch);

Looks like the special import syntax converts the function to run at build time.

https://github.com/oven-sh/bun/blob/c3bf97002d6f0b117060dabf...

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.

Hey, author here. Thank you so much for pointing this out, youre not the first. I'm updating the post.

I was waiting for a writeFilePromise to show up, should have guessed they'd be name spaced.

I remember feeling like they snuck that feature in without a lot of fanfare. Seems like it was easy to miss!