DEV Community: Paul

A Fig That Works Anywhere — FaiTerm

Paul — Thu, 01 Oct 2026 15:03:12 +0000

The Problem

Do any of these sound familiar?

How do I get Fig on Windows?
When will Fig's command suggestions ever land on Linux?
Can Fig's completion also use my command history?
If I work over SSH, how do I get Fig-style completion without installing anything on the remote machine?

Preface

If you spend a lot of time on the command line, you already know the pain: too many commands, too many flags, and no completion worth the name. What you want is something like the candidate list from an input method editor — except for shell commands. That thing was Fig — https://app.fig.io

But Fig only ever shipped a Mac version. Nobody else got to experience that kind of command-line completion. Fig did open-source its completion data, though: https://github.com/withfig/autocomplete — a pile of JavaScript that describes how commands should be suggested.

1. Fig: The Best Terminal Completion There Ever Was

Fig has since been acquired by Amazon and renamed Amazon Q.

Once you had it installed and enabled, you'd type git in iTerm2 and a dropdown would appear at the right of your cursor — add, commit, push, rebase… each with an icon and a one-line description. Keep typing git checkout and it wouldn't list filenames; it would list the branches that actually exist in your repo. Type npm run and it would list the real scripts from your package.json. Type docker and it would list the containers and images actually on your machine.

That was Fig's entire ambition: give the terminal you already use an IDE-style completion experience.

What Fig got right

1. It didn't build another terminal.

This was Fig's smartest move. Every other approach at the time either forced you onto a brand-new terminal emulator (Warp, Tabby) or left you stuck with the weak completion of the day. Fig chose to piggyback instead — it supported macOS Terminal, iTerm2, Tabby, Hyper, Kitty, WezTerm, Alacritty, and even the embedded terminals in VS Code, the JetBrains IDEs, and Android Studio. You changed nothing. You installed an app.

2. Completion quality came from human-written declarative specs, not guesswork.

This was Fig's real moat. It didn't try to guess what should follow git checkout. It defined a completion spec — a declarative schema describing a CLI's subcommands, options, and args. The withfig/autocomplete repo held specs like that for hundreds of popular CLIs, maintained by 400+ contributors. That data was Fig's single most valuable asset, and the part it open-sourced under the MIT license.

2. Fig's Limitations

Fig proved that "declarative specs + a GUI dropdown" was the right direction. But the way it built that direction locked it in.

1. It only supported macOS

This wasn't "macOS only for now" — from 2021 until the day it shut down, Windows and Linux stayed officially "in progress."

The reason:

It depended on the Accessibility API, which is macOS-specific. Windows and Linux have no equivalent, and "where is the cursor on screen" is simply an unsolvable problem there.

The community pushed for Linux support from day one. The team opened discussion #14 (Linux) and discussion #15 (Windows). Neither shipped before the Fig name disappeared.

2. Recommendations were mostly static

Most of what Fig suggested was fixed. There was a dynamic portion too — branch names for git, directory candidates for cd — but that was about the extent of it.

If you've used fish, you know its history-based command suggestions are a fantastic feature. Or zsh with zsh-autosuggestions, which gives you something similar.

3. Specs were TypeScript code

This is the limitation that made Fig's assets genuinely unreusable by any other language.

Fig's specs were .ts files. They could contain callbacks like custom, postProcess, and generateSpec — real executable code:

// The shape of a Fig spec (illustrative)
const spec: Fig.Spec = {
  name: "git",
  subcommands: [{
    name: "checkout",
    args: {
      name: "branch",
      generators: {
        script: ["git", "branch", "--no-color"],
        postProcess: (out) => out.split("\n").map(b => ({ name: b.trim() })),
      },
    },
  }],
};

Data and logic were mixed together, and that data had to run inside Node before it could be evaluated.

So when a Go, Rust, or Dart project said "I want Fig's completion too," what it faced wasn't "read a JSON file" — it was "re-translate the function logic across hundreds of TS files."

So I forked it and started this project.

3. autocomplete (Dart): Rebuilding Fig's Most Valuable Part as a Portable Engine

Repo: github.com/littlewrite/autocomplete (a fork of withfig/autocomplete; the new code lives in dart/)

3.1 The assets I inherited

Measured against Fig's repo:

Metric	Count
Logical commands	1463
Alias entries	736
Physical JSON documents	1464
Coverage	`git`, `docker`, `kubectl`, `npm`, `cargo`, `brew`, `terraform`, `aws`, `az`, `gcloud`, `flutter`, `codex`, `claude` …

Most of that repo is object definitions — spec definitions. A small fraction is dynamic code, i.e. spec generators: git branches and cd directory candidates, for instance, are produced by executing code.

3.2 The rewrite: a JSON-first architecture

Since most of autocomplete is TypeScript object definitions, they can be converted into JSON files and deserialized back into objects at use time. That means Java can read it — and so can Go, Rust, and Python. All of them can read the same JSON and deserialize it into spec objects that just work. The dynamic functions are only a small part, and they're straightforward to convert.

This is the fork's biggest design improvement:

Static data → pure JSON: command names, descriptions, options, subcommands, args, template, loadSpec links, and the command and splitOn of script generators — all of it lives in JSON.
Dynamic behavior → stable handler ID references: wherever code needs to run, the JSON keeps only a reference:

{
  "name": "branch",
  "generators": [{
    "script": ["git", "branch", "--no-color"],
    "postProcess": { "handler": "git.branches", "version": 1 }
  }]
}

There is no executable code in the JSON.

4. Improvements Over Fig

Feature 1: JSON abstraction — one dataset, N languages

Once specs become JSON, a completion spec stops being "some TypeScript code" and becomes a language-agnostic data contract. Three things define it:

A JSON Schema (schema/completion-spec.schema.json) — what the data looks like;
A physical layout convention — flat commands at <first-letter>/<command>.json, namespaced commands at <first-letter>/<namespace>/.../command.json, with index.json mapping logical names to files only;
A handler contract — {"handler": id, "version": n}, where the field's position determines the callback signature (custom / postProcess / trigger / generateSpec / alias / script each have an explicit Dart signature).

That makes extensibility remarkably clean:

Switching languages: any language with a JSON parser — Go, Rust, Java, Kotlin, Swift, C#, JS — can implement its own handler registry and reuse the exact same JSON catalog without changing a single byte. Dart is simply the first implementation that works end to end, not the only one.
A handler ID is a versioned API boundary: the version field makes semantic changes traceable. If the semantics don't change, old documents keep working; if they do, you bump the version and old and new implementations can coexist.
Data updates require recompiling no host at all: adding a command to the catalog means adding a JSON file, not editing code in any language.

Reusing Fig's specs in another language would have meant "re-translating the logic" — fully translating several thousand files into the target language, an enormous amount of work. By defining the spec as JSON, that work disappears entirely. What's left is the dynamic functions, and they're only a small fraction, so porting them is far quicker.

Feature 2: A genuinely platform-independent runtime (pure Dart, no Flutter dependency)

The package's lib/ contains no dart:io and does not depend on Flutter. It asks the host for exactly two injection points:

// 1. Where does the data come from — a function that returns a string
typedef JsonAssetReader = Future<String> Function(String relativePath);

// 2. The completion environment — directories, processes, environment variables
abstract class CompleteAdapter { ... }

Feature 3: The adapter abstraction — the completion environment itself is replaceable

For Fig, the completion environment was the local machine. This project abstracts it into an interface:

abstract class CompleteAdapter {
  String? getEnv(String key);
  Future<String> resolveCwd(String cwd, Shell shell);
  Future<List<FileSystemEntry>> listDirectory(String path);
  Future<ProcessRunResult> runProcess(List<String> command, ...);
}

So completion can work in three completely different worlds:

Adapter	Scenario
Local (`dart:io`)	The local shell
SSH / SFTP	A remote server: directory listings go over remote SFTP, and a generator's `script` is executed on the remote host
Noop	Disconnected / unknown host — never silently falls back to the local filesystem

Add to that a Shell enum covering bash / zsh / fish / pwsh / powershell / cmd / xonsh / nushell, plus a per-session pathSeparator (only native Windows consoles use \; WSL / Git Bash / macOS / Linux / remote Unix all use /) — cross-platform isn't a slogan here, it's semantics nailed down one at a time.

Yes: you can use it from Dart on any platform, any OS — even the Web.

Feature 4: Streaming completion — static results immediately, slow ones later

Completion splits into static and dynamic. With streaming completion, the user gets the static suggestions right away, and as soon as the dynamic code finishes executing, those results keep filling into the list. The whole thing just feels faster.

Static: the subcommands, options, and args hardcoded in the spec. They're sitting in the local JSON; they come back in microseconds.
Dynamic: anything that requires actually running a process. git branch, docker ps, kubectl get pods, directory listings…

Fig's approach was compute everything, then show it all at once. What the user experienced: type, wait, and only once everything had been generated did the full list of suggestions appear. Over SSH, where you're at the mercy of the network, that experience is nothing short of disastrous.

autocomplete provides SuggestionRequestMode.staticThenFinal, which splits a single computation into progressive frames:

Frame	Contents	Arrives
`staticPartial`	The subcommands / options / args from the spec	Immediately
`staticPartial` (second frame)	New subcommands produced by `generateSpec`	Once generated
`sourcePartial`	The result of one dynamic source (one frame per source)	As each generator finishes
`finalResult`	The authoritative, complete result	Once everything is done

Which means the experience becomes: by the time you've finished typing, suggestions are already in front of you; while you're reading and choosing, the rest keep filling in. Not "wait for every command to finish computing before anything appears."

5. FaiTerm: A Cross-Platform Command-Completion Terminal

FaiTerm is a terminal GUI built with Flutter. Command completion is built in — no extra configuration needed.

5.1 Why build a terminal

Because I want to use it on Windows and Linux — and on Android and mobile devices too.

Tools like Fig piggyback on someone else's terminal, so they have to obtain two things:

The cursor's on-screen coordinates — only available through macOS's Accessibility API; Windows and Linux have no equivalent.
What you're currently typing — only available by inserting a pseudo-terminal passthrough layer between the terminal and the shell.

Those two constraints mean it can never cross platforms.

So flip it around: what if the terminal is mine?

Where's the cursor? I render it — of course I know.
What are you typing? I receive the keystrokes, and I maintain the edit buffer.
What's the shell, and what's the current directory? I spawned the PTY — I know.

Otherwise you're stuck depending on the Accessibility API, a pseudo-terminal passthrough layer, and system accessibility permissions — and cross-platform becomes extraordinarily hard.

5.2 Command history suggestions

On top of autocomplete's dynamic suggestions, FaiTerm also suggests commands based on your history. Compared to zsh-autosuggestions, FaiTerm's history completion gives you multiple choices at once.

I use that plugin myself, and most of the time it's excellent. But there's one annoyance: when two commands are very similar, unless you type something that differentiates them, you can't bring up the other suggestion. That's the pain point I ran into after using the zsh plugin for a long time.

5.3 What FaiTerm can do today

Beyond completion, it's a terminal you can genuinely live in.

Capability	Notes
Multi-tab terminal	Native Pty; local and remote share one interaction model
Command completion	spec + history + notes + AI, merged into one list
Multi-protocol connections	SSH / SFTP / Telnet / FTP / serial, unified into a single connection list
SFTP file management	Dual-pane, drag and drop, transfer queue
AI chat and Agent	Can bind to a terminal and execute automatically; dangerous-command blocking + approval modes
Knowledge base + RAG	Notes are searchable; `#` completes straight into the command line
Command history	Stored in SQLite, searchable, filterable by window / host
Themes	600+ terminal color schemes, light/dark paired, following the app's appearance
Cross-platform	macOS / Linux / Windows / Android / iOS / HarmonyOS

6. Try It Out

FaiTerm

Website: https://www.faiterm.com

Current version: v1.0.9. Download directly:

Platform	Artifacts
macOS	dmg (Apple Silicon / Intel / universal), pkg
Windows	exe, msix (x64 / arm64)
Linux	AppImage, deb, rpm, zip

Install it and it just works — no Fig to install first, no accessibility permissions to grant, no background service to run separately.

Bug reports, complaints, and feature requests are all welcome:

GitHub: https://github.com/littlewrite/FaTerm
For the Chinese-speaking community, there's also a QQ group: 1028280069

autocomplete (Dart)

If you're not here for FaiTerm but want to wire a completion engine into your own project, just use the package directly:

Repo: https://github.com/littlewrite/autocomplete — package docs are in dart/README.md.

dependencies:
  autocomplete:
    git:
      url: git@github.com:littlewrite/autocomplete.git
      path: dart
      ref: feat_dart_v2

It does not depend on Flutter. It runs on the CLI, on desktop, on mobile, and on the Web — all you have to provide is "a function that reads a string" and "a completion environment."

If you work in Go / Rust / Java / Kotlin / Swift / C# / JS, you're especially welcome to come run this JSON catalog.

That's exactly the problem JSON-first set out to solve: the spec data doesn't need rewriting, you just implement the handler contract. Dart is the first implementation to work end to end, not the only one.

Equally welcome is help with the completion specs themselves — is a CLI you use every day incompletely covered, or missing entirely? Come open a PR; adding one JSON file is all it takes.

7. Closing

A huge thank you to Fig and to the other developers who contributed to the community — the declarative completion spec, withfig/autocomplete.

autocomplete-dart builds on that: it takes the most valuable part Fig left behind — that spec asset — and rebuilds it from "code that can only run inside Node" into "a data contract any language and any platform can read." JSON for the data; an abstracted adapter so the completion environment itself is replaceable.

Fig's story ended on macOS.
This story continues in FaiTerm, no longer bound to any single platform.

Appendix: Key Links

FaiTerm website: https://www.faiterm.com
github.com/littlewrite/autocomplete — the JSON-first Dart implementation (MIT)
withfig/autocomplete — Fig's spec repo (now Amazon Q Developer CLI, MIT)
Amazon acquires Fig (TechCrunch, 2023-08-29)
inshellisense #258: Fig is sunsetting
Kiro CLI: Upgrading from Amazon Q Developer CLI
Design docs: docs/v3-json-first-architecture.md, docs/json-driven-specs.md, docs/json-spec-generation-rules.md, docs/remote-spec-distribution.md (all in the autocomplete repo)

Cursor vs Trae vs Kiro vs GitHub Copilot: My Honest 2-Year Review of 4 AI IDEs

Paul — Mon, 16 Mar 2026 01:51:20 +0000

Two Years, Four Mainstream AI IDEs, and Honest Paid-Subscriber Feedback — Not an Ad, Just a Real-World Pitfall Guide

This article is about my real experience with four tools: Cursor, Trae, Kiro, and GitHub Copilot. I’ll walk through how I got into each one, what feels great in day-to-day use, and where each one breaks down. If you’re deciding which IDE to use next—or you’re already unhappy with your current setup—I hope this hard-earned experience helps.

That said, tools are always personal. What works for me may not work for you. If your experience is different, or you think I missed a better setup, feel free to challenge me—discussion is exactly how we all get better.

I: My AI Coding Journey

GitHub Copilot: From “Old-School Typing” to “Tab-Driven Coding”

When people talk about AI coding, Copilot is hard to ignore. In 2023, when it moved from preview into mainstream use, I was an early adopter. It felt revolutionary at the time: type a few characters and it can complete an entire line, paragraph, or function. I jumped from “manual typing” to “trust the Tab key” almost overnight.

I’m a heavy JetBrains user, and VS Code never felt like home to me. Copilot’s strength is that it works across environments: not only VS Code, but also an official IntelliJ IDEA plugin. That gave my existing workflow a smooth AI upgrade. In 2023–2024, “IDEA interaction + Copilot completion quality” was my productivity sweet spot. I paid for it for two straight years, and it became foundational to my workflow.

Completion tip: Copilot pushed me to write clearer comments. The clearer I described intent in natural language, the better its completions became. That also improved my code readability.

Cursor: Shifting from Manual to Automatic

Cursor represented a new paradigm: not just completion, but conversation-driven development.

Talk to me,
Code for me.

When this capability first appeared, it was a shock to the industry. While Copilot was still optimizing Tab completion, Cursor was already handling higher-level reasoning and generating large code blocks from natural language prompts.

I started using Cursor in 2024. At that time there was no IDEA plugin, so I had to work in VS Code, which took some adjustment. My prompting skills were also weak at the beginning, so it didn’t click immediately. But after adapting to the workflow, I hit a second major productivity jump.

Kiro: Following the Leader, with Growing Pains

Because Cursor could be unstable in some network environments, I looked for a backup. That’s when I found Kiro. It started as Amazon Q and later became a standalone AI IDE. As an early user, I had a long free period, and when Cursor failed, Kiro often saved me.

Kiro is also VS Code-based, so onboarding was easy after using Cursor. The purple theme grew on me too. As an AWS product, it appears feature-complete: code completion, chat coding, diagnostics, and more.

But “has features” and “feels good to use” are very different things. Kiro has had more basic product bugs than any AI IDE I’ve used. I’m not talking about model hallucinations; I mean UI and interaction bugs in the product itself. That’s especially frustrating when expectations are high for a company known for infrastructure reliability.

Trae: A Late Entrant with Strong Engineering Discipline

I had seen Trae ads for a long time, but only started using it deeply in early 2026. I use the international version and subscribed with a local Visa card. By then, I was fully comfortable with VS Code-like IDEs.

My first impression: Trae is extremely polished in fundamentals. The UI is clean, response is fast, and localization is excellent. There are reports that the team rewrote major VS Code internals in Rust. True or not, large projects feel very smooth. After months of use, I can say this: touching so much low-level architecture while staying this stable is genuinely impressive. (Yes, this is also a subtle shot at Kiro 😏)

Of course, I’ve used Trae for less time than the others, so my view may evolve.

Chapter II: Deep Comparison — The Devil Is in the Details

Enough background. Here’s a direct breakdown of strengths and weaknesses from daily, high-intensity use.

GitHub Copilot: The Best Tab Experience

Positioning & price: $10/month. Its biggest advantage is ecosystem reach. You can use it in VS Code, the IntelliJ suite, Vim, and Neovim.

Subscribe once, tab everywhere

Core strengths:
1. Completion quality: Years of iteration still make its line/block completion speed and accuracy top-tier.
2. Ecosystem fit: Deep GitHub integration gives it strong context awareness for repos, style, and team habits. In JetBrains, it still feels best-in-class.
Core weakness (Agent mode):
1. Slow/inaccurate context retrieval: It often misses the right files unless you repeatedly guide it.
2. Whole-file rewrite behavior: This is my biggest pain point. Instead of focused edits, it tends to regenerate full files, which causes:
  - Unwanted formatting/style churn: comments, spelling, and style get changed even when not requested.
  - Higher breakage risk: full-file rewrites raise the chance of introducing regressions.

Bottom line: Copilot is an elite “Tab accelerator.” But if you want an autonomous project-aware partner for complex tasks, it can feel behind newer AI IDE workflows.

Kiro: Backed by a Giant

Positioning & price: $20/month (1000 points) at entry level. No free fallback model after points run out, so AI functions stop hard.
Core strengths:
1. Claude-based intelligence: Good reasoning and instruction following for most engineering tasks.
2. Spec-driven mindset: Useful for teams that prioritize strict, document-first workflows.
Core weaknesses (frustrating details):
1. Visible product bugs: From completion edge cases to UI glitches.
2. Painful file reference UX: In chat, you often have to manually type file names. In large projects with similar names, this is a productivity killer.
3. Fragile image handling: The model may not support images, but the IDE allows image content. Accidentally pasting rich text with images can break the session.
4. Long-context slowdown: It starts strong, then degrades into very slow “one-line edit, one-step think” behavior in late-stage refinements.
5. Expensive token economy: $20/1000 points can disappear quickly on long-context tasks. Several full-time users around me report ~$40/month as the practical minimum.

What Kiro taught me: Control context aggressively. Split weakly related tasks into separate sessions. Precisely scope files with @ references instead of relying on broad retrieval.

Trae: An Elegant Swiss-Army Knife

Positioning & price: $10/month entry plan with excellent value.
Core strengths:
1. Excellent fundamentals: UI, performance, stability, and localization are consistently strong.
2. Efficient workflow design: Its agent tends to follow: Find rules -> Retrieve code -> Read context -> Think -> Edit -> Check -> Fix -> Summarize It uses retrieval and proactive context compression, which helps reduce token waste.
3. Strong Chinese/local adaptation: Especially useful for Chinese-language workflows and local ecosystems.
Core weaknesses (trade-offs of its philosophy):
1. Overkill for tiny tasks: The full process can feel heavy for simple edits or translations.
2. Code-first bias: Outside coding tasks, it may ask for project structure before proceeding.
3. Session concurrency limits: Compared with some competitors, parallel multi-chat workflows feel more constrained.
4. “Prepare first” tendency: Even with precise instructions and file targeting, it may still perform extra retrieval before acting.

My take on Trae: Polished, powerful, and methodical. Great for substantial tasks; less ideal for lots of micro-edits.

Cursor: The Gold-Standard All-Rounder

Positioning & price: $20/month (with more flexible plans now).
Why it still feels best overall: Most pain points from other tools are either absent or better handled.
- Project-level understanding: Strong repository awareness without constant manual file tagging.
- Fast and focused edits: Usually edits targeted blocks instead of rewriting full files.
- Reliable baseline experience: Fewer product-level bugs in day-to-day use.
- Flexible model fallback: Auto mode can bridge gaps when premium quotas are exhausted.
- Smooth interaction model: Chat, edit, and file operations feel tightly integrated.
Biggest drawback: In mainland China, reliable access to top overseas models (like Claude) usually requires a stable proxy/VPN setup.

III: Summary & Selection Guide — Find Your Coding Partner

So which one should you choose?

GitHub Copilot: Your Tab Booster
- Best for: Developers who want AI enhancement inside their existing IDE workflow.
- One-liner: If you want stronger coding flow without changing your toolchain, Copilot’s cross-IDE plugin ecosystem is hard to beat.
Cursor: Your General-Purpose AI Coding Partner
- Best for: Developers ready to embrace conversation-first coding and able to handle connectivity requirements.
Kiro: Your Process-Heavy Contractor
- Best for: Teams that are deeply tied to AWS and strongly prefer spec-driven, documentation-first delivery.
Trae: Your Automated Workshop Lead
- Best for: China-based developers, especially those on local stacks, who care about cost-efficiency and structured automation.
- One-liner: Excellent fundamentals, strong localization, and highly automated flow.

I welcome discussion—and disagreement.

Extra Notes (Detailed Comparison)

Here’s the short practical version from real usage:

Copilot is still the best pure Tab completion experience, especially if you use multiple IDEs.
Its Agent mode is weaker: context lookup can miss, and full-file rewrites often create noisy diffs.
Kiro can solve real tasks with Claude-class reasoning, but UX issues and point-based billing can make long sessions expensive.
Kiro taught me to aggressively manage context and explicitly scope files to save tokens.
Trae is very strong on product quality and token efficiency, but can feel heavy for tiny, non-coding tasks.
For larger tasks, Trae’s structured flow is reliable and cost-effective.

How to visualize dependencies in Golang

Paul — Wed, 24 Sep 2025 14:06:10 +0000

Background

I encountered an issue while building a golang project recently. Even though I specified the version of a dependency package, the version number was automatically upgraded during the build process. I didn't understand why at the time. Later, I learned about the go mod graph command, which lists all dependencies. I tried it, but it wasn't intuitive at all; I still had to copy the output into a text editor to search for information.

So, I searched online for related tools.

Other Tools

Search terms: Go Module dependency visualization

There are many tools available online. Most solutions use graphviz, echarts, or generate images. I tried a few.

graphviz is a powerful tool, but it requires separate installation. The generated SVG files aren't very readable either, especially when there are many dependent packages. For example, look at this one:

So, I turned to echarts.

Wow, it looks quite nice! The mouse hover feedback is good, and the color scheme is vibrant.

The echarts solution is beautiful, but not practical. With SVG I could at least search for package names; with this echart version, the package names aren't displayed.

My Solution

Alright, enough complaining. The problem still needs solving. Today, I'm introducing a visualization tool for go mod graph — gmchart.

gmchart

github: https://github.com/PaulXu-cn/go-mod-graph-chart

Installation

go get -u github.com/PaulXu-cn/go-mod-graph-chart/gmchart

Check if the installation was successful like this:

gmchart --help

Usage of ~\go\bin\gmchart:
  -debug int
        is debug model
  -keep int
        start http server not exit

Usage

Navigate to your Golang project directory and run the command:

go mod graph | gmchart

This should automatically open your browser. If it doesn't, open it manually.

Visit http://127.0.0.1:60306 to see the result.

As you can see, it renders the dependencies into a dependency tree. You can see which layer a particular package is introduced in, which is very intuitive. The webpage contains an SVG, making it easy to find a specific package—just use Ctrl+F to search.

Summary

After searching for so long, why wasn't there a suitable tool?

I thought about it. Visualization is a front-end specialty. Front-end developers don't typically use Golang. Those who do are rare, and among those, even fewer are interested in the go mod graph functionality. So, it fell to us back-end developers to create this tool.

Sigh~