Nayeem Rahman

Does the second `custom://a//a.ts` not satisfy that format? It seems usable as a base. I wasn't sure about the first one since it technically has an empty pathname, but apparently...

I agree, I think `unstable` should be where e.g. `check` is, but unfortunately it belongs where it is currently is as well. This is another reason we should remove tsconfigs...

> Removing it for `Deno.emit()` would severely limit the ability to use `Deno.emit()` as a multi-purpose compiler/transpiler/typechecker. I'm not saying we should remove configuration, but we shouldn't blindly grab tsc's...

Ref https://github.com/denoland/deno_graph/issues/167

As I alluded to in https://github.com/denoland/deno_graph/issues/167#issuecomment-1200089544, config files shouldn't be in the same specifier pool as modules, we should factor that out to a separate set of roots

Long term we should do this with #132 instead, and associate import assertion errors with each import. With per-import errors being a third kind on top of resolution errors and...

This is a must for proper import assertion handling. Import assertion errors should be stored under each of these, not occupy module slots.

> however, because of `roots` and `loader` being required it's not possible to derive `Default` trait. Maybe we could use `CreateGraphOptions::default(roots, loader)` method? I think normally those would be excluded...

https://github.com/denoland/deno_install/blob/4d960274a86fa46265ca5ba9adc01a2405baded1/install.sh#L62-L64 -- are you not seeing this?

That would mean there is a `deno` in your PATH. Have you confirmed that `deno --help` doesn't work after seeing that output?