fix(bundler): Fix statement ordering issue

[kdy1]

Note: I postponed denoland/deno#8597.

---

swc_bundler:

• Reduce binary size by reducing usage of visitor / folders.
• Handle export * and export { default } from same source. (Bundler repeat importing issue denoland/deno#8530, Deno bundle regression in both 1.5.4 and 1.6.0 when a module re-exports both * and default denoland/deno#8679)
• Fix ordering of statements. (Bundler results in incorrect ordering of code denoland/deno#8545)
• Sort statements in wrapped modules. (Uncaught ReferenceError when running bundle created with Deno 1.5.x denoland/deno#8211 (comment))
• Exclude default export while handling export *.
• Exclude export { default } and export { foo as default } while handling export *.
• Make statements from same module to be injected together. (Deno miss-bundles THREE.js from Skypack denoland/deno#8620)

swc_ecma_transforms:

• fixer: Handle assignments in the callee of new correctly.
• fixer: Handle seqence expression in the callee of new correctly.

---

I investigated further.

8620 fails, and it's expected.

With lots of logging code and in debug build, all other tests pass.

But when I removed logging code and tested in release mode,

• deno_8211_1

also fails.

Try: 8620

  for &dep in &deps {
            let cycles = self.graph.all_simple_paths(dep, idx);
            dbg!(&cycles);  
            if !cycles.is_empty() {
                self.emit_cycles(cycles);
                continue;
            }
            // We jump to another module.
            eprintln!("Jumping to dep: `{}`", dep);
            self.insert_inner(dep, false, dejavu, delayed, &[]);

            eprintln!("Done: one dep of `{}`: `{}`", idx, dep);
        }
        eprintln!("Done: deps of `{}`: `{:?}`", idx, deps);

hangs with

[bundler/src/bundler/modules/sort.rs:601] next_idx = 195
Checking `195`
[bundler/src/bundler/modules/sort.rs:519] &cycles = []
Jumping to dep: `194`
Checking `194`
Skipping `194`
Done: one dep of `195`: `194`

So... all_simple_paths hangs in certain condition.

Fix for petgraph

I'm trying to capture all graph operations in parsable form, and I'll use it to debug petgraph.

Tests

• deno_7288_1:
• deno_8188_01:
• deno_8188_02:
• deno_8188_03:
• deno_8188_full:
• deno_8189:
• deno_8211_1:
• deno_8246:
• deno_8302:
• deno_8314_1:
• deno_8314_2:
• deno_8399_1:
• deno_8399_2:
• deno_8481_1:
• deno_8486_1:
• deno_8530:
• deno_8573:
• deno_8620:
• deno_8627:
• exec_deno_exec__deno_8211__case2__entry_ts:
• exec_deno_exec__deno_8545__entry_ts:
• merging_order_01:
• oak_6_3_1_application:
• oak_6_3_1_example_server:
• oak_6_3_1_example_sse_server:
• oak_6_3_1_mod:
• reexport_01:
• std_0_74_0_http_server:

[kdy1]

I found lots of bugs of petgraph...
I just workarounded most of them to reduce time, but I found a bug which is hard to workaround.

Currently failing tests except 8620 fails due to bug of petgraph.

For memo, 8620 can be easily fixed by implementing more rules for collecting requirements.
So maybe I have to fix petgraph..

[kdy1]

I found that almost all tests pass if I wrap DiGraphMap from petgraph with custom struct.
I'm not sure what's going on...