Add ModuleKind to graph and be returned by Resolver.resolve

[dsherret]

Was talking to @bartlomieju today so this is a quick summary of the discussion. For denoland/deno#12648 we'll need a way to identify if .js/MediaType::JavaScript files are CJS or MJS. This can be determined a number of ways in node (ex. a package.json having say "type": "module") which is information that's known by the node compat resolvers in the CLI. Perhaps it would be useful to introduce a ModuleType enum that has members ModuleType::Cjs & ModuleType::Mjs and the Resolver.resolve method could return that value which would then be stored in the graph.

[kitsonk]

I would prefer something just like a field named kind (type is always a pain in Rust, and actually a bit "wrong" label) and a value like:

enum ModuleKind {
  Amd,
  CommonJs,
  Esm,
  Script,
  SystemJs,
  Umd,
}

While I don't believe swc currently supports AMD/SystemJs/UMD, tsc does, and we should accomodate everything that we likely would be able to understand. That doesn't mean we wouldn't eventually able to do dependency analysis on AMD and SystemJS though. We could easily contribute that dependency analysis up stream though.

The biggest question I have is how this would be used. I assume the use case is to interrogate the graph when loading a module to determine how it should be loaded?

[kitsonk]

I was just in the code on another purpose... we would need to consider how the above would related to this, and whether we would merge all of this into a single tagged enum, or restructure it in some way so that EsModule (the existing "code" struct):

#[derive(Debug, Clone, Serialize)]
#[serde(untagged)]
pub enum Module {
  Es(Box<EsModule>),
  Synthetic(Box<SyntheticModule>),
}

All the above would be effectively the same struct as EsModule but just with a tag. Need to think about it a bit more.

[kitsonk]

The biggest question I have is how this would be used. I assume the use case is to interrogate the graph when loading a module to determine how it should be loaded?

@bartlomieju and I discussed. It is used in the situation where when loading the module into a runtime, it needs to be interrogated, and for example if an ESM module is loading a CJS module, it needs to go through a process to "convert" the CJS module to an ESM module on the fly.

[bartlomieju]

This should be named ModuleKind instead of ModuleType as the latter is already used in deno_core.

[kitsonk]

I've started working on this... I am going to collapse everything into a single Module struct with a ModuleKind.