feat: export metadata object in stage 2

[eduardoboucas]

Functionally, this PR adds a metadata object to the exports of the stage 2 file. Right now, this object contains just a url property containing the file path of each function, like so:

// Existing export
export const functions = {
  func1: [Function],
  func2: [Function]
}

// New export
export const metadata = {
  func1: {
    url: "file:///some/path/to/func1.ts",
  },
  func2: {
    url: "file:///some/path/to/func2.ts",
  }
}

This will allow the bootstrap code to match log locations to function names.

Also, it includes some housekeeping:

• Node tests were moved from test/ to test/node/
• Deno tests added to test/deno/
• CI updated to run Deno tests
• Added stage 2 test

[eduardoboucas]

This test was long overdue because we're dynamically generating code so it's good that we validate it as early as possible.

[mraerino]

always confused that tests are not colocated with the implementation like in Go 😅

[mraerino]

this scares me a bit. why are you doing this line by line instead of just calling JSON.stringify on a whole object?
also: did you forget a .join(",")?

[eduardoboucas]

Great point! Updated in 71bed63.

[mraerino]

wow, importing code in the code that generated it is next level 😄

[eduardoboucas]

I know, right?! 🤯

[mraerino]

could you do the same here if you're already on it?

[eduardoboucas]

This is not serialisable to JSON, though. The output of this will be something like:

export const functions = {"func1": func0, "func2": func1};

... where func0 and func1 are the imported modules.

[khendrikse]

I saw the change of moving tests into more organised folders. I do really like structuring all of this a little bit. I remember looking into the code there are files in the src folder that are organised in folders, and some that are not. Maybe it might be interesting in the future to organise the src folder in general. Because it might give a little bit more context to both the code and the tests. (for example, we have bundle.ts that is just an export of an interface, while there are other files that export functions).

Right now I'd almost say it might be clearer for the deno tests to just be a part of the deno folder because it'll clearly show the existing tests, and might lead to an incentive to write more when changing something there or adding something there.

Also: total nitpicking here, no prioritisation at all :)

[eduardoboucas]

I saw the change of moving tests into more organised folders. I do really like structuring all of this a little bit. I remember looking into the code there are files in the src folder that are organised in folders, and some that are not. Maybe it might be interesting in the future to organise the src folder in general. Because it might give a little bit more context to both the code and the tests. (for example, we have bundle.ts that is just an export of an interface, while there are other files that export functions).

Right now I'd almost say it might be clearer for the deno tests to just be a part of the deno folder because it'll clearly show the existing tests, and might lead to an incentive to write more when changing something there or adding something there.

Also: total nitpicking here, no prioritisation at all :)

Good thoughts! Let's iterate on this.