feat(cli): --ext parameter for run, compile, and bundle

[Cre3per]

Adds --ext to deno run, closes #5088

Additionally

• Adds --ext to deno compile and deno bundle
• Deprecates deno eval --ts (Was already marked for removal in code, this PR exposes the deprecation to the CLI)
• :warning: Changes the default value of deno fmt --ext from ts to js for consistency. If CLI default arguments are part of deno's API, this violates semver and needs to be undone. Personally, I'd prefer TypeScript to be the default for all commands, but JavaScript was chosen here https://github.com/denoland/deno/issues/5088#issuecomment-1008360178. Changing the default value to TypeScript would not avoid the breaking change, because the main branch is inconsistent already (fmt vs eval).

You'll find a new TODO concerning deno_ast in the changes. I intend to address that TODO before this PR is merged, after I get confirmation that the PR is otherwise ok.

[kt3k]

Is it correct for #17269 to close this? @dsherret

[dsherret]

Only if it increases my closed issue count.

[dsherret]

Thanks and sorry, this was done in error. I meant to close #17112, when I copy and pasted the issue number gh did some auto complete weirdness that must have selected this one.

[aapoalas]

@dsherret Opinion on the breaking change to cat file.js | deno fmt - / deno fmt extensionless use case: Should that be allowed to land and break in 1.31 or should that part be made to wait until 2.0?

[Cre3per]

@aapoalas While implementing the extension->media-type mapping function in deno_ast, I've noticed a potential future problem this PR is introducing.

I'm using deno run as an example, this affect all subcommands with --ext.

We want deno run file.xxx to have the same effect as deno run --ext xxx file.

deno run file.ts ends up at MediaType::from(module_specifier), which maps file extension to MediaType.
deno run --ext ts file ends up at MediaType::from_content_type(module_specifier, content_type), which maps the media type string to MediaType.

There isn't a media-type string for every file extension, particularly the .d.* file extensions don't have their own media-type strings.
These file extensions are mapped to an ambiguous media-type such as text/typescript, and behavior could differ compared to invoking deno with a file with extension. This could result in failures, eg. in deno_ast's parsing.rs get_syntax(), which has different handling for MediaType::TypeScript and MediaType::Dts.

.d.* files aren't relevant right now, because we're limiting the possible values for --ext with clap.
As far as I can tell, the values currently allowed for --ext have unique media-type strings, meaning this is not a problem right now. Should the list of allowed --ext values be extended in the future, this could be a bug with no quick solution.

---

The limiting factor is the media-type string. I chose to use the media-type strings, because that's how FetchCacher could communicate types to deno_graph already. Ditching the media-type strings and finding a new way to transport MediaType to deno_graph directly could solve this problem. I can't estimate the feasibility for this change with my current knowledge.

The impact right now are some comments in deno_ast explaining why some MediaTypes have unique mappings to media-type strings, while others don't. I don't have that PR ready yet.

I thought I'd let you know about this issue so you have a chance to revoke your approval before this hits in deno_ast.

[Cre3per]

I had a look at your commits, looks good. Thanks for your feedback @dsherret!

[dsherret]

@Cre3per and sorry for my delay on this one! I did a few commits just now because I want to get this in the release (happening in a little bit).

[kt3k]

Now deno run - seems handling the stdin as JavaScript by default:

$ echo "console.log(1 as any)" | deno run  -        
error: The module's source code could not be parsed: Expected ',', got 'as' at file:///Users/kt3k/denoland/deno_std/$deno$stdin:1:15

  console.log(1 as any)
                ~~
$ echo "console.log(1 as any)" | deno run --ext ts -
1
$ deno -V
deno 1.32.0

Is this expected? (Some test cases in std failed by this change)

[Cre3per]

@kt3k That's unintentional. I'm adding a test case for deno run - and working on a fix.

UPDATE: Fixed in https://github.com/denoland/deno/pull/18391