feat(gonx): add static analysis dependency detection by chadxz · Pull Request #99 · naxodev/oss

chadxz · 2026-01-27T01:26:20Z

Why?

The existing go-runtime dependency detection requires Go to be
installed and a go.work file to be configured. This is problematic
for teams where not everyone has Go installed (e.g., frontend devs)
or CI environments without Go.

This adds a new static-analysis strategy that uses tree-sitter
WASM to parse Go source files directly, requiring no Go toolchain.

Addresses #98

How?

Added dependencyStrategy option: 'go-runtime' | 'static-analysis'
| 'auto'
Implemented tree-sitter based import extraction (parser-init.ts,
extract-imports.ts)
Implemented go.mod parsing for module paths and replace directives
(parse-go-mod.ts)
Built import map with per-project replace directive scoping
(build-import-map.ts)
Used longest-prefix matching for import resolution with caching
(resolve-import.ts)
Added 'auto' strategy that tries go-runtime first, falls back to
static-analysis with warning logging
206 unit tests covering all components
E2E tests for full integration
Documentation in docs/static-analysis.md

nx-cloud · 2026-01-27T01:44:27Z

View your CI Pipeline Execution ↗ for commit 2d2dff5

Command	Status	Duration	Result
`nx affected -t lint test`	❌ Failed	11s	View ↗
`nx-cloud record -- nx format:check`	✅ Succeeded	4s	View ↗

☁️ Nx Cloud last updated this comment at 2026-02-09 18:02:09 UTC

NachoVazquez · 2026-01-27T01:44:28Z

Thanks @chadxz ! I really appreciate it. I will take a deeper look in the morning.

NachoVazquez · 2026-01-27T01:47:06Z

For now, there are some issues in the pipeline. Let me know if you need anything from me there.

chadxz · 2026-01-27T03:33:17Z

I don’t know what’s wrong with the tests, they’re running fine for me locally, I’ll have to take a look tomorrow.

NachoVazquez · 2026-01-27T14:06:57Z

It can be a Windows thing.

NachoVazquez

Praise: This is a great PR. I think most of my observations are around the docs and making sure we don't create confusion about the need for a go work with the default dependency resolution technique, but the rest looks good!

NachoVazquez · 2026-01-27T14:12:44Z

packages/gonx/docs/static-analysis.md

+The static analysis strategy is useful when:
+
+- Go is not installed (CI environments, frontend-only developers)
+- You don't use `go.work` files


suggestion: I don't think this assertion is true. This plugin was designed to work without the go.work by default. You can see it here https://youtu.be/_5aXT0-xCyA?t=85

I will have to investigate. Initial investigation made me think it was required.

I tested go list -m -json in a monorepo without go.work - it returns {"Path": "command-line-arguments"} with exit code 0. go-runtime is silently detecting zero dependencies rather than failing.

I saw in a previous commit that some work was done to remove dependence on go.work for build and serve executors, but perhaps still dependency detection still relies on go.work at the root of the monorepo?

Oh interesting, I might have missed this.

Oh, you are absolutely right. go list -m -json only works when there is a go.work or a root go.mod.

Well, this does it. Let's use your strategy as the default, then.

Let's nuke the old way of doing things, since I'm moving away from needing a go.work on this project.

Thank you @chadxz , this is a great discovery.

NachoVazquez · 2026-01-27T14:13:50Z

packages/gonx/docs/static-analysis.md

+
+- Go is not installed (CI environments, frontend-only developers)
+- You don't use `go.work` files
+- You want faster dependency detection


note: I also beleive this is true, but it would be awesome to benchmark both approaches so we can give some solid numbers on how fast it is.

I think this would be most notable in monorepos with many go projects as the overhead would be in spawning the processes. I'll see if i can come up with something.

preliminary benchmarks show that go list is surprisingly fast but file io dominates at larger scale which doesn't change for either solution. So performance-wise this is a lateral move overall. Probably should just omit the performance discussion from the docs.

Sounds good! Thank you for your research!

packages/gonx/docs/static-analysis.md

NachoVazquez · 2026-01-27T14:38:58Z

packages/gonx/src/graph/static-analysis/index.ts

+ *
+ * This is an alternative to the go-runtime strategy that:
+ * - Does NOT require Go to be installed
+ * - Does NOT require go.work file


suggestion: let's skip this one, since the go-runtime doesn't need go.work either.

NachoVazquez · 2026-01-27T14:44:09Z

packages/gonx/src/graph/static-analysis/resolve-import.ts

+ * Cache for sorted module paths to avoid re-sorting on every resolve call.
+ * Key is the Map reference (via WeakMap), value is the sorted array.
+ */
+const sortedPathsCache = new WeakMap<Map<string, unknown>, string[]>();


praise: nice optimization

NachoVazquez · 2026-01-27T14:46:43Z

packages/gonx/src/graph/types/go-plugin-options.ts

+  /**
+   * Strategy for detecting dependencies between Go projects.
+   *
+   * - `go-runtime` (default): Uses `go list -m -json` command (requires Go installed)
+   * - `static-analysis`: Uses tree-sitter WASM parsing (no Go required)
+   * - `auto`: Tries go-runtime first, falls back to static-analysis if Go unavailable
+   */
+  dependencyStrategy?: DependencyStrategy;


Praise: Nice, I don't rule out moving to static analysis in the next major release if it is stable for everyone.

We are actually making it the default now! Good work.

NachoVazquez · 2026-02-02T02:12:15Z

Hey @chadxz, just to take it from where we left. In my mind, the missing piece here is to replace the existing dependency detection with yours; we don't need to keep the old strategy.

chadxz · 2026-02-02T12:43:32Z

Understood. Also need to address ci failure

NachoVazquez · 2026-02-02T13:48:30Z

Understood. Also need to address ci failure

Yeah, hopefully it is only a missing dependency that we need to declare explicitly.

Why? ==== The existing go-runtime dependency detection requires Go to be installed and a go.work file to be configured. This is problematic for teams where not everyone has Go installed (e.g., frontend devs) or CI environments without Go. This adds a static-analysis strategy that uses tree-sitter WASM to parse Go source files directly, requiring no Go toolchain. How? ==== - Chose web-tree-sitter (WASM) over tree-sitter (native) to avoid native compilation requirements — the WASM build runs everywhere Node.js does with no platform-specific binaries. - Investigated web-tree-sitter's module export shape across environments (native Node.js vs ts-jest). Found that ts-jest returns the raw Emscripten Module instead of the expected named exports. Solved with a static import in production code and a jest.mock normalizing the module shape in tests, keeping type assertions out of production code entirely. - Validated go.mod parsing against the Go module reference spec, covering quoted/unquoted module paths, single-line and block replace directives, versioned replacements, and inline/multi-line comments. - Verified import extraction handles all Go import patterns: single, grouped, aliased, dot, blank, raw string literals, and cgo pseudo-import filtering. - Used longest-prefix matching for import resolution with per-project replace directive scoping and caching. - Adopted jest.mock('fs/promises') patterns matching the rest of the gonx test suite instead of introducing memfs as a new dependency. - 206 unit tests and E2E tests pass locally; format and build checks clean. ---- Addresses naxodev#98.

chadxz · 2026-02-07T00:53:01Z

@NachoVazquez I've pushed a few commits that I think may address the ci failure. I've got the refactor to remove the existing implementation in favor of this new one but I ran across an issue with the web-tree-sitter types that I have submitted a fix for to clean up. Not a blocker, though.

NachoVazquez · 2026-02-09T14:07:25Z

Thanks, @chadxz. I was out for the weekend, so I didn't reply before. Taking a look at the new changes.

NachoVazquez · 2026-02-09T14:12:15Z

I see we have new issues now, that's progress, also I think we are still mentioning the old go mod list method as the default, let's change that, actually, my idea is to completly remove the old dependency calculation strategy and use yours as the only one.

chadxz · 2026-02-09T14:42:32Z

@NachoVazquez I pushed the commit replacing the dependency resolution with the tree-sitter implementation. This should also address the current CI failure.

Why? ==== The go-runtime strategy required Go to be installed and a go.work file to function, making it unusable in CI environments or for frontend developers. The static-analysis strategy (tree-sitter) has no such requirements and produces equivalent results. Maintaining three strategies (go-runtime, static-analysis, auto) added complexity without meaningful benefit. How? ==== - Removed go-runtime strategy, auto strategy, and the dependencyStrategy option entirely - Made static analysis the only code path in createDependencies - Deleted all go-runtime utility files and associated types - Added unit tests for the static-analysis index module - Simplified e2e tests to remove strategy-specific describe blocks - Updated docs and README to reflect the single approach

NachoVazquez · 2026-02-09T18:04:19Z

@chadxz, the tests are failing again. As a test, comment out the Windows runner from the matrix. Let's see if the issue is reproducible outside of Windows.

NachoVazquez requested changes Jan 27, 2026

View reviewed changes

chadxz force-pushed the feat/gonx-static-analysis-dependency-detection branch 2 times, most recently from c251c09 to 77d7601 Compare February 5, 2026 23:35

chadxz force-pushed the feat/gonx-static-analysis-dependency-detection branch from 77d7601 to dcd08b6 Compare February 6, 2026 00:15

chadxz force-pushed the feat/gonx-static-analysis-dependency-detection branch from ffd2999 to 2d2dff5 Compare February 9, 2026 14:45

Uh oh!

Conversation

chadxz commented Jan 27, 2026

Why?

How?

Uh oh!

nx-cloud bot commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NachoVazquez commented Jan 27, 2026

Uh oh!

NachoVazquez commented Jan 27, 2026

Uh oh!

chadxz commented Jan 27, 2026

Uh oh!

NachoVazquez commented Jan 27, 2026

Uh oh!

NachoVazquez left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NachoVazquez commented Feb 2, 2026

Uh oh!

chadxz commented Feb 2, 2026

Uh oh!

NachoVazquez commented Feb 2, 2026

Uh oh!

chadxz commented Feb 7, 2026

Uh oh!

NachoVazquez commented Feb 9, 2026

Uh oh!

NachoVazquez commented Feb 9, 2026

Uh oh!

chadxz commented Feb 9, 2026

Uh oh!

NachoVazquez commented Feb 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nx-cloud bot commented Jan 27, 2026 •

edited

Loading