Feedback from looking at the Nx go plugin for use

[chadxz]

I thought you may be interested in my feedback after investigating your Nx go package and deciding to instead roll my own.

I was:

• unhappy that it requires go.
• unhappy that it requires .work file

Because my use case was much smaller than what this plugin covers, I decided to create my own.

It uses treesitter web, the wasm version, to parse the go files to understand imports. To parse go.mod it uses regex since that file format is relatively simple.

It ignores .work entirely since it is my understanding that this file is not required to build go apps.

My version focuses only on detecting dependencies between go apps - it doesn't use createNodeV2 at all, instead relying on go apps to already be detected as apps via project.json.

Anyway, I do think there's an opportunity to simplify the dependencies.

Wishing you all the best!

[NachoVazquez]

Hey @chadxz !

Thanks for the detailed feedback! I really appreciate you taking the time to investigate and
share your approach. Let me address each point:

Go Requirement

You're right that requiring Go for dependency detection is unnecessary. The main reason we use go list -m -json is to get the module path and directory mapping, but as you noted, this could be derived from parsing go.mod directly. That said, we considered it reasonable to assume Go was installed if the developer was working on a Go project, but I can see how that's not always true.

Interestingly, we already use regex for parsing imports (not treesitter, but same concept):
/import\s+(?:(\w+)\s+)?"([^"]+)"|\(([\s\S]*?)\)/

The go list -m -json call is only needed (and convenient) to get module metadata (specifically the Path and Dir fields). Your approach of parsing go.mod directly and inferring the directory from the file location would work for most (if not all) monorepo setups.

go.work Requirement

This should not be required! The addGoDotWork flag is opt-in, and the generators only update
go.work if it already exists:

  // From application/generator.ts
  if (isGoWorkspace(tree)) {
    addGoWorkDependency(tree, options.projectRoot);
  }

If you're hitting a scenario where go.work is mandatory, that's a bug I'd like to fix.
Can you share more details about what error or behavior you encountered?

createNodesV2

Fair point - if you already have project.json files and just need dependency detection, the
full project inference is overkill.

The plugin uses createNodesV2 to:

• Auto-detect Go projects via **/go.mod glob
• Determine if it's an app or library (by checking for package main + func main( or cmd/
  directory)
• Auto-generate targets: build, test, serve, tidy, lint, generate, nx-release-publish
• Add release configuration for nx release

Your approach of relying on explicit project.json and only detecting dependencies is a valid, lighter-weight solution for simpler setups.

We acknowledge that this plugin was designed for people coming from Go to Nx, not the other way around. For that, this plugin is great because it lets you use a single nx.json file instead of multiple project.json files, and the original source code changes very little.

Would You Be Interested in Contributing?

Specifically:

1. A staticModuleDetection option that parses go.mod directly instead of calling go list.
2. If there's a bug where go.work feels required, I'd love a reproduction case so I can fix it.

Thanks again for the thoughtful feedback!