Repository: TypeScript
Issue: `--explainFiles` differentiate `import type ...` vs `import`
Labels: Suggestion,Experience Enhancement

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

explainFiles "import type"

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [X] This wouldn't change the runtime behavior of existing JavaScript code
* [X] This could be implemented without emitting different JS based on the types of the expressions
* [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [X] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## ⭐ Suggestion

I would like the `--explainFiles` behavior to differentiate between `import type` and `import` runtime imports in its printout.

## 📃 Motivating Example

```
c:/project/src/server-side/contract
  Imported Types via '../server-side/contract' from file 'c:/project/src/client-side/app.tsx'
           ^^^^^
```

## 💻 Use Cases

I am looking for suspected non-`import type ...` imports that are poisoning our build, bleeding code from non-client files ultimately into client bundles (before maybe tree-shaking them out again).  At best, this impacts build performance.  I know that better code organization could help avoid confusing import chains and improper imports - that's what I'm trying to untangle it for.

I am using the output from `--explainFiles` to recognize the various patterns and reconstitute a dependency graph:

```ts
const targetPattern = /^(?!\s)(.*)/;
const importedViaPattern = /^  Imported via (['"])(.*)\1 from file '([^']*)'/;
const includePattern = /^  Matched by include pattern (['"])(.*)\1 in '([^']*)'/;
const referencedViaPattern = /^  Referenced via (['"])(.*)\1 from file '([^']*)'/;
const libReferencesPattern = /^  Library referenced via (['"])(.*)\1 from file '([^']*)'/;
const typeLibraryPattern = /^  Type library referenced via (['"])(.*)\1 from file '([^']*)'/;
const fileRedirectsPattern = /^  File redirects to file '([^']*)'/
const compilerOptionsPattern = /^  Library '(.*)' specified in compilerOptions/;
const filesPattern = /^  Part of 'files' list in/;
const implicitTypeLibraryPattern = /^  Entry point for implicit type library/;
```

There seems to be no difference in the output between an `import` and an `import type` so my dependency graph can't cull the type imports that won't be emitted to the next stage in the build pipeline.