nx-go VS nxpansion

Your go projects will share the go dependencies from the go.mod file in the root. Checkout https://github.com/nx-go/nx-go for getting started. Also, when generating a library you can follow the same approach as an app except you change it from app to lib.

As your applications grow in complexity, so do the tools required to build those applications. The Nx Build Framework and its accompanying product [Nx Cloud])(https://nx.app/) have made it easier than ever for JavaScript (and even non Javascript) developers to manage their build pipelines. Through its executors and tasks runners, Nx provides developers with an extensible monorepo to help developers manage dependencies between applications, create build scripts, cache results, and much more. When paired with Nx Cloud, these build artifacts can be cached in the cloud and distributed across build servers to speed up your CI Pipeline.

With this complexity, however, developers need a way understand how their build process is performing. CI platforms have come a long way help deliver these insights about your pipelines and workflows, but if you're using Nx, you're still probably left wondering "What is going on when I run nx affected build?" Nx Cloud is a great first step to see build performance and statistics, but that data still lives in the Nx Cloud and isn't queryable or correlatable. This is where @nxpansion/opentelemetry-tasks-runner comes in. This plugin instruments every command ran by the Nx CLI using OpenTelemetry, allowing you to generate traces and send them to the observability platform of your choice. Below are example traces sent to Honeycomb from an example application. Whether you're using stock Nx build executors, using incremental builds and Nx Cloud build cache, or you're using the Nx Cloud distributed build agents, and whether you're using GitHub Actions, CircleCI, or a custom CI setup, the OpenTelemetry Tasks Runner can instrument you build commands.