Support named exports on bundles.

[kitsonk]

Fixes #3283

This PR re-exports the exports of the main module passed on the command line. So if your main module looked something like this:

export { foo } from "./foo.ts";
export const bar = "bar";
export default "baz";

And you generated it into a bundle named myLib.bundle.js you could consume it like this:

import myLib, { foo, bar } from "./myLib.bundle.js";

There was a partial solution tabled in #3283 to provide all the exports of the main module as the default export for the bundle. Looking into how to determine what is exported out of the main module, it was actually fairly easy to just generate the named export code.

[ry]

This file is the output of deno bundle command? I think it would be good to automatically generate it during the tests.

[kitsonk]

👍

[kitsonk]

The only problem is that we don't support a pre-req in our integration tests, and I can't be guaranteed execution order or dependency. So to get one integration test to output it, and one integration test to consume it seems fragile, right?

[hayd]

If you run and consume in a single test it wouldn't be fragile.

[kitsonk]

Yes, but our integration tests don't support two invocations of Deno.

[ry]

You’d need to write a custom one. See for example the js_unit_tests https://github.com/denoland/deno/blob/master/cli/tests/integration_tests.rs#L41

[ry]

This patch is awesome. I tried it with std/http/server.ts and it worked.

I did get a failure when trying it with std/encoding/yaml.ts. I think this is because yaml.ts doesn't export any symbols directly, but rather via another module. Do you have any ideas about how this could be supported? I have the same problem with the documentation generator on the website...

[kitsonk]

Cool, need a test case. I will have a look and see what is wrong with that.

[kitsonk]

Ok, it appears that it does export a symbol named __export, of which it has runtime code which determines what exports gets named. So, what I need to figure out is if that symbol is walkable to to the other SourceFiles, to get their symbols to determine what their names are, etc... until we have all the exports determined.

[kitsonk]

Ok, I found a better compiler API that will give you all the exported members names, even if they are re-exports of another module. The one downside is that it also picks up "type only" exports as well. They should just result in undefined values in the resulting module, but I don't fully like that because some people looking at the bundle would think there is something there (including someone trying to consume the bundle in an intelligent editor). I have put some logic in there to try to weed out things that aren't "real", but I have also opened microsoft/TypeScript#35183 to see if there is some cleaner way.

[ry]

@kitsonk I've modified the test - I think this is functionally equivalent to what you had before. PTAL.

[kitsonk]

Ha! I was working on it right now... just haven't had as much as I would like, but yeah, this looks like what I was doing. Thank you.

[kitsonk]

LGTM

[kitsonk]

Ha! I was working on it right now... just haven't had as much as I would like, but yeah, this looks like what I was doing. Thank you.

[ry]

LGTM