Kitson Kelly

It is something we might consider for `Deno.emit()` but unlikely to be considered for `deno bundle` as it is intended to be straight forward and low config.

That is a diagnostic structure in excess of 560mb. I can't believe that would be useful. Likely the fix will be to truncate the diagnostic messages at some limit.

That is why the issue isn't closed.

The first two I don't believe are valid URLs. `Deno.emit` now handles all specifiers via the Rust URL struct (Deno `ModuleSpecifier`) which gives things like relative resolution when resolving modules....

If that is the case, @kt3k can you provide more details about what panics are happening and where?

Yes, I agree... what appears to be failing is the media type detection. It is detected here: https://github.com/denoland/deno/blob/81d73f2987c65463c0f2653f31d3d29d8db1986c/cli/specifier_handler.rs#L494 which comes from: https://github.com/denoland/deno/blob/81d73f2987c65463c0f2653f31d3d29d8db1986c/cli/media_type.rs#L64-L78 So the proper fix would be to add...

@kt3k I am not sure I agree. It is entirely up to us how we decide to assign a media type to a URL. Why wouldn't the logic of "if...

> With the above change, `op_load` is called with the specifier `foo://mod.ts.ts/` for unknown reason, and the source code is not found for this op call. That is because we...

@kt3k I had some challenges with this before, in a different way. We might be able to work around it. We already have a construct for dealing with special handling...

@nayeemrmn removing it for code the Deno runs is one thing... Removing it for `Deno.emit()` would severely limit the ability to use `Deno.emit()` as a multi-purpose compiler/transpiler/typechecker. I would be...