@typeslayer/analyze-trace 0.1.0 â 0.1.11
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +13 -17
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -2,12 +2,9 @@
|
|
|
2
2
|
|
|
3
3
|
Analyze TypeScript compiler trace events to identify performance bottlenecks and compilation hot spots.
|
|
4
4
|
|
|
5
|
-
Initially, this started as a full rewrite of [@typescript/analyze-trace](https://github.com/microsoft/typescript-analyze-trace)*. That rewrite was successful, new features were added during the development of [TypeSlayer](https://github.com/dimitropoulos/typeslayer).
|
|
5
|
+
Initially, this started as a full rewrite of [@typescript/analyze-trace](https://github.com/microsoft/typescript-analyze-trace)*. That rewrite was successful, and new features were added during the development of [TypeSlayer](https://github.com/dimitropoulos/typeslayer) (where it was rewritten a second time in Rust).
|
|
6
6
|
|
|
7
|
-
<sub>
|
|
8
|
-
> \* why did it need a full rewrite? it's been unmaintained for many years and also I ([dimitropoulos](https://github.com/dimitropoulos)) wanted to know every detail of how it works. That ended up being very useful because there were some things that are exceedingly interesting (like some of the instantaneous events for limits being hit) that the original tool ([intentionally](https://github.com/microsoft/typescript-analyze-trace/issues/1), in some cases) completely ignores things that are actually quite fundamental to the goal of TypeSlayer
|
|
9
|
-
> also the original was intended as a end-of-the-pipeline CLI tool (giving nice human readable format, but only experimental JSON support) and the rewrite is though of as a middle-of-the-pipeline tool (1st-class JSON support).
|
|
10
|
-
</sub>
|
|
7
|
+
> \* <sub>why did it need a full rewrite?<br /><br />well.. it's been unmaintained for many years and also I <a href="https://github.com/dimitropoulos">dimitropoulos</a> wanted to learn every detail of how it works. academically speaking, rewrites are great for that. when I looked deeper, though I saw some exceedingly interesting things (like some of the instantaneous events for type limits) that the original tool completely ignores (<a href="https://github.com/microsoft/typescript-analyze-trace/issues/1">sometimes intentionally</a>), yet some are actually quite fundamental to the goal of TypeSlayer!<br /><br /> also the original was intended as a end-of-the-pipeline CLI tool (giving nice human readable format, but only experimental JSON support) and the rewrite is though of as a middle-of-the-pipeline tool (1st-class JSON support). </sub>
|
|
11
8
|
|
|
12
9
|
## CLI Usage
|
|
13
10
|
|
|
@@ -63,21 +60,20 @@ In a perfect world, all events created by TypeScript's trace machinery should be
|
|
|
63
60
|
|
|
64
61
|
Type-level limits that were hit during the type checking, including:
|
|
65
62
|
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
does not report to the user (unless you're a [TypeSlayer](https://github.com/dimitropoulos/typeslayer) user ð).
|
|
63
|
+
| Depth Limit | Error Triggered |
|
|
64
|
+
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
65
|
+
| `checkCrossProductUnion_DepthLimit` | triggers `TS(2590) Expression produces a union type that is too complex to represent.` |
|
|
66
|
+
| `checkTypeRelatedTo_DepthLimit` | triggers `TS(2859) Excessive complexity comparing types '{0}' and '{1}'.` or `TS(2321) Excessive stack depth comparing types '{0}' and '{1}'.` |
|
|
67
|
+
| `getTypeAtFlowNode_DepthLimit` | triggers `TS(2563) The containing function or module body is too large for control flow analysis.` |
|
|
68
|
+
| `instantiateType_DepthLimit` | triggers `TS(2589) Type instantiation is excessively deep and possibly infinite.` |
|
|
69
|
+
| `recursiveTypeRelatedTo_DepthLimit` | This is not currently considered a hard error by the compiler and therefore does not report to the user (unless you're a [TypeSlayer](https://github.com/dimitropoulos/typeslayer) user ð). |
|
|
70
|
+
| `removeSubtypes_DepthLimit` | triggers `TS(2590) Expression produces a union type that is too complex to represent.` |
|
|
71
|
+
| `traceUnionsOrIntersectionsTooLarge_DepthLimit` | This is not currently considered a hard error by the compiler and therefore does not report to the user (unless you're a [TypeSlayer](https://github.com/dimitropoulos/typeslayer) user ð). |
|
|
72
|
+
| `typeRelatedToDiscriminatedType_DepthLimit` | This is not currently considered a hard error by the compiler and therefore does not report to the user (unless you're a [TypeSlayer](https://github.com/dimitropoulos/typeslayer) user ð). |
|
|
77
73
|
|
|
78
74
|
### Type Graph
|
|
79
75
|
|
|
80
|
-
>
|
|
76
|
+
> _note_:
|
|
81
77
|
> As fate would have it, when [TypeSlayer](https://github.com/dimitropoulos/typeslayer) moved from Node.js to Rust to be a Tauri app, this entire package was _again_ rewritten in Rust. Since this version was fully up-and-running first, and the original has some issues, I decided to just not delete this and publish it in case others stuck in the Node ecosystem (ðŠĶ) find it useful.
|
|
82
78
|
>
|
|
83
79
|
> This particular feature is only in the Rust version. If you'd like a wasm-build of it or something lemme know.
|