Your feedback on beta of nx-go 3

Question

Your feedback on beta of nx-go 3

utarwyn opened this issue a year ago · 25 comments

🚀 nx-go v3 enters beta phase

Would you like to help us prepare for this major step in the project? Need to test integration with Nx 17/18 right now? Or simply tell us about your experience using the plugin? You've come to the right place!

Please comment here or create a new ticket with the various problems encountered, mainly on the following items:

New generators (init, preset, convert-to-go-mod)
Project graph performance
Migration V2 -> V3

Things to change already reported :

#108
#111

If needed, you can use the updated playground located in https://github.com/nx-go/nx-go-playground

Note

This version aims to offer similar features to v2. We will process all tickets proposing additions in versions 3.x.

This issue is a follow-up to the work carried out in #103. I plan to release a stable version during Q1 2024.
We'd like to thank you in advance for all your feedback, which will help make the plugin more stable.

Answer 1 · 2024-02-21T23:54:12.000Z

Will you be releasing @nx-go/nx-go@beta? happy to help test this one!

Answer 2 · 2024-02-22T11:29:26.000Z

Everything looks great, well done!

Answer 3 · 2024-02-22T12:19:33.000Z

Sorry for the misunderstanding, I prepared this post in anticipation of releasing the beta. It is available now!
But thanks for the early feedback 🤝

Answer 4 · 2024-02-23T21:28:26.000Z

Will definitely give it a shot on some of our projects to see if there are any compatibility issues!

Thanks for all the effort!

Answer 5 · 2024-02-24T07:44:04.000Z

Tested 3.0.0-beta.0 with nx:18.0.4 and everything seems to work as expected.

Thanks @utarwyn!

Answer 6 · 2024-02-24T12:41:00.000Z

@utarwyn with the change to the linter args type from a string to string[] should there be a migration to update the existing configurations to split the original argument by space?

In my projects we have a value like "-config ./revive.toml" which will now need to be converted to ["-config", "./revive.toml"]. Its not a big deal but I wanted to raise it in case it is something you want to smooth out for other users.

Answer 7 · 2024-02-24T12:53:20.000Z

@utarwyn with the change to the linter args type from a string to string[] should there be a migration to update the existing configurations to split the original argument by space?

Yes, that's a great idea! I hadn't thought about this migration, so I'll add it to the to-do list.

Answer 8 · 2024-02-26T12:50:07.000Z

Aside from the abovementioned schema change to string[], I have had no issue upgrading so far! Great job!
I'm looking forward to the actual release!

Answer 9 · 2024-03-13T00:09:12.000Z

Hi @utarwyn , still learning go and I use this package for my personal project. Thanks for the hardwork.
Just a question, the previous version do have a single go.mod file in the root of the project and dependencies are listed in that file. Now, each project have each go.mod file. Where should I run the go get command? In the root dir or inside the project?

Answer 10 · 2024-03-13T12:16:52.000Z

Hi @utarwyn , still learning go and I use this package for my personal project. Thanks for the hardwork. Just a question, the previous version do have a single go.mod file in the root of the project and dependencies are listed in that file. Now, each project have each go.mod file. Where should I run the go get command? In the root dir or inside the project?

Hello @rodentskie, thanks for the kind words!

Version 3 of nx-go uses a multi-module Go workspace by default. This explains why each project has its own go.mod file. Currently, as explained in the Go documentation, the go get command must be executed for each module (so, in each project).

It might be interesting to have an executor in nx-go to run this command in all projects at once 👍

Note: you can revert to the old approach by deleting the go.work file and keeping a single go.mod file at the root of your project

Answer 11 · 2024-03-13T15:26:05.000Z

No issues until now! Just need more executors, for tidy and get.
I'm adding some custom executors to each project.json file, so I can run nx commands to tidy and get the go modules.
Even though it is not a big deal, it would be nice to have it on the plugin.
The 'get' i'm not using that much as the vscode plugin auto imports the packages, but the tidy is a must have.

usage:
nx affected -t tidy
nx get myapp needed/package
nx myapp:get needed/package

{
  // ...
  "targets": {
    // ...
    "tidy": {
      "executor": "nx:run-commands",
      "options": {
        "cwd": "{projectRoot}",
        "command": "go mod tidy"
      }
    },
    "get": {
      "executor": "nx:run-commands",
      "options": {
        "cwd": "{projectRoot}",
        "command": "go get"
      }
    }
  }
}

Answer 12 · 2024-03-13T18:06:09.000Z

@llucasshenrique
No issues until now! Just need more executors, for tidy and get.

Thank you for the feedback! Much appreciated 👍
I fully agree with you about adding these executors. We'll be able to do this in version 3.1, can you create a ticket about it?

Answer 13 · 2024-03-13T21:32:01.000Z

Hi @utarwyn , still learning go and I use this package for my personal project. Thanks for the hardwork. Just a question, the previous version do have a single go.mod file in the root of the project and dependencies are listed in that file. Now, each project have each go.mod file. Where should I run the go get command? In the root dir or inside the project?

Hello @rodentskie, thanks for the kind words!

Version 3 of nx-go uses a multi-module Go workspace by default. This explains why each project has its own go.mod file. Currently, as explained in the Go documentation, the go get command must be executed for each module (so, in each project).

It might be interesting to have an executor in nx-go to run this command in all projects at once 👍

Note: you can revert to the old approach by deleting the go.work file and keeping a single go.mod file at the root of your project

Thanks for the reply. Also, what I did was I created a custom executor exactly what @llucasshenrique did too. Hoping for it to be added in the next release.

Answer 14 · 2024-03-13T21:40:08.000Z

"install": {
    "executor": "nx:run-commands",
    "options": {
      "cwd": "{projectRoot}",
      "command": "go get {args.package}"
    }
  },

Sample usage:

nx install api --package=github.com/pulumi/pulumi-aws-apigateway/sdk

Added this one too.

Answer 15 · 2024-03-13T23:12:15.000Z

Also, I just ran an issue now. When I run go get or nx get api from my project I get some error.

❯ nx get api

> nx run api:get

go: slack-pr-lambda/api imports
        slack-pr-lambda/constants: package slack-pr-lambda/constants is not in std (/usr/local/go/src/slack-pr-lambda/constants)
go: slack-pr-lambda/api imports
        slack-pr-lambda/env: package slack-pr-lambda/env is not in std (/usr/local/go/src/slack-pr-lambda/env)
go: slack-pr-lambda/api imports
        slack-pr-lambda/logger: package slack-pr-lambda/logger is not in std (/usr/local/go/src/slack-pr-lambda/logger)
Warning: command "go get" exited with non-zero status code
———————————————————————————————————————————————————————————————————————————————————————————————

 NX   Ran target get for project api (1s)

   ✖  1/1 failed
   ✔  0/1 succeeded [0 read from cache]

The error above is because of my custom libraries.

Here is the current setup of my project.

.
├── app
│   ├── api
│   │   ├── bin
│   │   ├── handlers
│   │   ├── infra
│   │   └── routes
│   └── api.lambda
│       ├── bin
│       └── endpoints
└── library
    └── go
        ├── constants
        ├── env
        └── logger

Answer 16 · 2024-03-16T18:20:33.000Z

Definitely interested in something like #94 for nx-go 3.x. My use case would be goreleaser for multi-platform builds. While generators for goreleaser config would be nice too, I understand that this sort of thing might be outside the scope of the project, so I'll just leave it at a mention. I feel like simply supporting an arbitrary cmd input to the build executor would be enough for the core project and folks could just add their own generators within their personal workspaces to take care of the configuration plumbing required.

Answer 17 · 2024-03-19T12:00:28.000Z

Hi @utarwyn , just an update my usage of the project.

"tidy": {
  "executor": "nx:run-commands",
  "options": {
    "cwd": "{projectRoot}",
    "command": "go mod tidy"
  }
},
"download": {
  "executor": "nx:run-commands",
  "options": {
    "cwd": "{projectRoot}",
    "command": "go mod download"
  }
},
"install": {
  "executor": "nx:run-commands",
  "options": {
    "cwd": "{projectRoot}",
    "command": "go get {args.package}"
  }
},

These are the three custom rule I made in all of my apps and libraries.

The reason I added download rule is because the setup for go in github action has a built-in caching but somehow with multiple jobs in the workflow caching isn't working.

Combined nx affected, I only download packages on the affected projects and cache the path ~/go/pkg/mod and to be restored in proceeding jobs.

Edit

After some debug, I have a working caching for the go setup.

Answer 18 · 2024-03-19T15:41:22.000Z

@rodentskie
Hi utarwyn , just an update my usage of the project.

Thank you for the follow-up! These executors can be integrated into future versions of nx-go, of course 👍

Answer 19 · 2024-03-19T19:52:02.000Z

Hello! I have just published v3.0.0-beta.1 with following improvements:

Add a migration for executors options (#108)
Update test executor options (#111)

If you want to try it out, use this command:

nx migrate @nx-go/nx-go@beta

If all goes well, I propose to release the stable version by the end of the month! 🚀

Answer 20 · 2024-03-20T02:33:07.000Z

Hi team, it is my first time to implement CICD workflow with go (always with node). The go test really takes a lot of time, even though it only run ~7 seconds in my local machine.

I've tried the following:

npm run test
Use of my affected script
Running go test ./... inside the project working directory.

Everything I've tried has almost the same time of test.
Is it because of the monorepo setup? I've watched in the youtube videos, their tests run and exits right away.

Here is the actual CI of my project.

Edit

Additonal info, my tests are just dummy and no go routine implemented thoughout my project.

Sample

package handlers

import "testing"

func TestIndexRequestHandler(t *testing.T) {
	t.Logf("Running minimal example test")
	if false {
		t.Errorf("This should not fail")
	}
}

Answer 21 · 2024-03-20T14:38:25.000Z

Hi team, it is my first time to implement CICD workflow with go (always with node). The go test really takes a lot of time, even though it only run ~7 seconds in my local machine.

I've tried the following:
* npm run test

* Use of my `affected` script

* Running `go test ./...` inside the project working directory.
Everything I've tried has almost the same time of test. Is it because of the monorepo setup? I've watched in the youtube videos, their tests run and exits right away.

Here is the actual CI of my project.

Edit

Additonal info, my tests are just dummy and no go routine implemented thoughout my project.

Sample
package handlers

import "testing"

func TestIndexRequestHandler(t *testing.T) {
	t.Logf("Running minimal example test")
	if false {
		t.Errorf("This should not fail")
	}
}

This seems more appropriate for a discussion board than as a comment on this issue. Maybe @utarwyn it would be a good idea to setup the commuity feature on the repo or a discussion forum for these types of usage questions.

Answer 22 · 2024-03-20T18:00:05.000Z

Hello, thank you for the suggestion! I've just opened the discussions forum of the repository.

Please use it to ask more general questions about Golang or your personal installation 👍
And you can still create a ticket for a plugin related issue. I propose to talk only about the beta here

Answer 23 · 2024-03-21T22:31:16.000Z

Hi @utarwyn thank you for your time and effort with this project.

I'm new to nx and the last week has been a eye opener time with the project, and as I'm also a Go developer I came to this project.

I'm running the 3.0.0-beta.1 version and if I try to pass env vars to the build target I got the error:

** NX   Cannot convert undefined or null to object


TypeError: Cannot convert undefined or null to object
   at Function.keys (<anonymous>)
   at /Users/leopoldocaballero/Projects/yaydoo/node_modules/nx/src/utils/params.js:194:24
   at Array.find (<anonymous>)
   at validateObject (/Users/leopoldocaballero/Projects/yaydoo/node_modules/nx/src/utils/params.js:193:27)
   at validateProperty (/Users/leopoldocaballero/Projects/yaydoo/node_modules/nx/src/utils/params.js:346:9)
   at /Users/leopoldocaballero/Projects/yaydoo/node_modules/nx/src/utils/params.js:210:9
   at Array.forEach (<anonymous>)
   at validateObject (/Users/leopoldocaballero/Projects/yaydoo/node_modules/nx/src/utils/params.js:209:23)
   at validateOptsAgainstSchema (/Users/leopoldocaballero/Projects/yaydoo/node_modules/nx/src/utils/params.js:144:5)
   at combineOptionsForExecutor (/Users/leopoldocaballero/Projects/yaydoo/node_modules/nx/src/utils/params.js:432:5)**

I'm working with the nx@18.2.1

Edit

Digging a little bit I think the problem occurs here: https://github.com/nx-go/nx-go/blob/main/packages/nx-go/src/utils/execute-command.ts#L34

because if I run this in a process in node I get:

Welcome to Node.js v20.11.1.
Type ".help" for more information.
> Object.assign(undefined, {'test': 'value'})
Uncaught TypeError: Cannot convert undefined or null to object

Answer 24 · 2024-03-23T10:42:30.000Z

Hello @pitakill, thank you for the feedback about the beta!
I can reproduce it too. In the error stack you share with us, there's no mention of the nx-go code: it's actually an Nx bug that concerns "object" type executor properties, which is the case of the "env" property of the build executor in nx-go.

You can follow the issue here: nrwl/nx#22349
This should be fixed in nx 18.2.0!

Answer 25 · 2024-04-03T18:22:09.000Z

Hello! I'm excited to announce that the stable version is now out! Check the complete changelog here.

If you have any problems, please create new issues. Many thanks for your feedback!
I'm now going to start integrating new features for v3.1. Moving forward together 🤝