feat: add ModuleGraphError::TypesResolutionError

[dsherret]

Adds a new TypesResolutionError so that it's easier to identify which resolution errors are for type checking or not and enhance the error messages.

FYI @nayeemrmn. For some reason I can't add you as a reviewer.

[dsherret]

It doesn't really make sense to store resolution errors in the module slots, so changed this from ModuleGraphError to just ModuleError.

[bartlomieju]

FYI @nayeemrmn. For some reason I can't add you as a reviewer.

I added Nayeem to this repo. This should be fixed now.

[bartlomieju]

LGTM, I like this change, does it mean that we'll be able to not fail on wrong types specifier but still fail if the actual code can't be resolved?

[nayeemrmn]

LGTM.

Does it offer different functionality from just checking the type-only status of the graph branch when traversing? Feels like it should be a lot simpler to identify type-only graph arcs with #272

[dsherret]

LGTM, I like this change, does it mean that we'll be able to not fail on wrong types specifier but still fail if the actual code can't be resolved?

That was already possible before by using graph.walk(... { follow_types: false, .. }).errors(), which is what graph.valid()? seems to use under the hood.

Does it offer different functionality from just checking the type-only status of the graph branch when traversing?

@nayeemrmn I don't understand. Could you clarify?

Feels like it should be a lot simpler to identify type-only graph arcs with #272

I'm unsure if we should make that change anymore. It's now possible to have specifiers like "./a" resolve to a.js for code and a.d.ts for types

[nayeemrmn]

Does it offer different functionality from just checking the type-only status of the graph branch when traversing?

@nayeemrmn I don't understand. Could you clarify?

Nevermind, the ModuleGraphError enum is meant for when you're getting e.g. a list of errors from a graph without context, so you won't have the type-only traversal context I mentioned. It makes sense there.

Feels like it should be a lot simpler to identify type-only graph arcs with #272

I'm unsure if we should make that change anymore. It's now possible to have specifiers like "./a" resolve to a.js for code and a.d.ts for types

Yeah.. I'll see what to do with that PR. I still think we can get a flatter structure but will have to rethink it.