[WIP] feat: expose AST parser API to Deno namespace.

[littledivy]

Closes #3983

Exposes swc's AST parser API to the runtime behind the --unstable flag.

await Deno.ast("file1.ts"); // uses default options

Prior Art:
N/A - this feature is specific to the runtime compiler ops.

Corresponding command:
deno ast file.ts --unstable

Points:

• No extra crates included. Uses swc_utils.rs
• Better than using typescript's AST as it is faster and much easier to serialise.
• Returned AST can be typed. See https://github.com/swc-project/swc/blob/ea885df521031b6f913615975b6e76f6c08308bc/node-swc/src/types.ts#L1278. Will include that into the .d.ts .

[CLAassistant]

All committers have signed the CLA.

[SyrupThinker]

What is the reason for taking a file name and reading the file instead of passing name and source code to Deno.ast?
That'd be more in line with how Deno.{bundle, compile, transpileOnly} work.

[nayeemrmn]

I think we're supposed to support both:

namespace Deno {
  export type AstOptions = {
    /** Name of the file or URL of the module. Where applicable, it will be
     * downloaded and cached before being parsed. */
    name: string;
    // Other options...
  } | {
    /** Source of the module. It will be parsed without side-effect. */
    source: string;
    // Other options...
  };;

  export function ast(options: AstOptions): Module;
}

Or even simpler if the name should be provided either way.

[nayeemrmn]

Are these being put into the global scope or something?

[littledivy]

Nope, these are the AST return types but I'm unable to refer the Module type in deno.unstable.d.ts

[ry]

We are having an internal debate about whether we actually want this feature - we can't reach consensus. Because of that I don't want to land for 1.3.0. Removing the milestone.