How do I configure goland to recognize 'mod' packages?

Question

I am taking go1.11rc1 for a spin and the first thing I noticed is that goland does not recognize imports.

The goland version announcement says: "support for Go modules out of the box (formerly known as vgo)"

Anyone know how to fix this?

Problem:

1. Packages like "github.com/urfave/cli" colored red and hover text says: "Cannot resolve directory..."
2. Imported package items like "NewApp" in "app := cli.NewApp()" colored red and hover text says: "Unresolved reference ..."

Steps to reproduce:

1. Install go1.11rc1: remove the current install, install 1.11rc1, check version.
2. Create a new project directory outside the go path: mkdir pjg && cd pjg
3. Create a go.mod file: go mod init github.com/stevetarver/pjg
4. Add a package to the project: go get github.com/urfave/cli

go.mod file now looks like:

module github.com/stevetarver/pjg/v1

require github.com/urfave/cli v1.20.0 // indirect

Create main.go:

package main

import (
    "fmt"
    "log"
    "os"

    "github.com/urfave/cli"
)

func main() {
    app := cli.NewApp()
    app.Name = "boom"
    app.Usage = "make an explosive entrance"
    app.Action = func(c *cli.Context) error {
        fmt.Println("boom! I say!")
        return nil
    }

    err := app.Run(os.Args)
    if err != nil {
        log.Fatal(err)
    }
}

View main.go in goland, and hover over red text to see problem.

• mod packages are stored in $GOPATH/pkg/mod/
• goland version: 2018.2.1
• go version: go1.11rc1 darwin/amd64

Notes:

• $GOPATH is set correctly - go get put the package in the right place, GOPATH in env matches goland preferences.
• Setting goland preferences Go -> GOPATH -> Module GOPATH to /Users/starver/code/go/pkg/mod did not fix this.

Solution 1

The answers on this site worked for me. Basically, enable go modules in GoLand via:

Make sure Go Modules integration is enabled in settings (Preferences / Settings | Go | Go Modules), and GOPATH indexing is disabled (Preferences / Settings | Go | GOPATH | Index entire GOPATH).

As soon as I did this, the red imports went away and everything worked.

Solution 2

GoLand support

The latest version of GoLand implemented support for vgo and go modules, but it hasn't caught up with go1.11rc1 syntax changes. Just in case it helps someone in the interim, I am going to document the things I tried and their problems and successes.

TL;DR: Don't put your project inside $GOPATH AND create your new project as a "Go Module (vgo)" type, OR turn that setting on for existing projects.

With go1.11rc1 installed as your global go, there are three basic use cases for go mod projects in GoLand...

Create a new project inside $GOPATH:

1. Create a new project of type "Go Module (vgo)": File -> New, select "Go Module (vgo)"
2. Set your project directory to something inside $GOPATH: $GOPATH/src/github.com/stevetarver/insidegopath
3. Create your main.go file referencing a package that does not exist in your $GOPATH.
4. Add that package to your imports.

Using go get the GoLand way via vgo as described in the gif here:

1. Click on the import package.
2. Click on the red inspection bulb.
3. Click on "Sync packages of ...".
4. FAIL: go: go mod -sync is now go mod tidy

Using go get the GoLand embedded terminal way:

1. Open the embedded terminal.
2. go get your import.
3. FAIL: ᐅ go get github.com/urfave/cli go get: warning: modules disabled by GO111MODULE=auto in GOPATH/src; ignoring go.mod; see 'go help modules'

Let's turn that variable on and try again:

1. Note: the terminal plugin preferences provide no way to set environment variables.
2. Set GO111MODULE=on: Open Preferences -> Appearance & Behavior -> Path Variables, and add GO111MODULE=on.
3. Exit the terminal, retry, restart GoLand, retry, same failure as above.
4. env | grep GO111MODULE in the terminal produces nothing.
5. NOTE: if this would have worked, it would have been a bad solution - GoLand does not appear to have a per-project settings for this - that variable would have been turned on for all projects which would break those that aren't ready for go modules.
6. According to this answer, you can create a custom command line launcher to include this env var, but eeuuwww - how would you keep track of when to start GoLand normally and when to use the command line launcher?

You could set GO111MODULE=on in your shell init script, but that would break all the projects that don't use go modules yet.

You could also prefix each go command with the env var: export GO111MODULE=on; go get github.com/urfave/cli or create a go shell script wrapper in your project directory that does this for you.

None of these are really workable solutions, but part of the point of go modules is escape from the dreaded go workspace, so read on, it gets better

Create a new project outside $GOPATH:

1. Create a new project of type "Go Module (vgo)": File -> New, select "Go Module (vgo)"
2. Set your project directory to something outside $GOPATH
3. Fix up your go.mod: the generated file contains module "outsidegopath", but we want something like module github.com/stevetarver/outsidegopath. This is a bit wonky - GoLand will try to rewrite go.mod and remove parts of the path. Repeat a couple times and it will stop trying.
4. Create your main.go file. If you create this through the ide as a go file, it will contain package outsidegopath. Fix that to be package main.
5. Now you can go get github.com/urfave/cli and it is fetched to $GOPATH/pkg/mod as expected.

Add go mod support to an existing new project:

This turned out to be really simple - best way of working with go modules in GoLand:

1. Open Preferences: Go -> Go Module (vgo), and check "Enable Go Modules (vgo) integration"
2. Works as described above - but you create your own go.mod with go mod init module-name.

Solution 3

The module management should be easier with Go 1.13 (Aug. 2019):

The GO111MODULE environment variable continues to default to auto, but the auto setting now activates the module-aware mode of the go command whenever the current working directory contains, or is below a directory containing, a go.mod file — even if the current directory is within GOPATH/src.

This change simplifies the migration of existing code within GOPATH/src and the ongoing maintenance of module-aware packages alongside non-module-aware importers.

That means the all "Don't put your project inside $GOPATH" part will no longer be needed.
As long as there is a go.mod file, modules will be recognized, from command-line or from an IDE like Goland.

Comments

[dlsniper]

GoLand will support Go 1.11 RC1 from 2018.2.2, which at the time of writing is next week, and the error ` go: go mod -sync is now go mod tidy ` will be fixed then.

[Steve Tarver]

Thanks for the info @dlsniper - that is an amazingly quick follow up to the new go rc. Note - I am a vocal advocate of JetBrains products and maintain a personal All Products subscription - not finding fault, just sharing in case it helps someone. Previously, JetBrains has published the opinion that they would wait for new language versions to gel before officially supporting new features - pragmatic and reasonable. I thought there might be a quarter before supporting big changes like this were supported and the info would be more durable.

[Arnaud P]

IIUC, this should be the accepted answer. Certainly spot on for me 🙏

[s0xzwasd]

Agreed with Arnaud :)

[Vikram Hosakote]

Yes, this is the correct answer and worked for me too. My go project doesn't have go.mod and the steps in intellij-support.jetbrains.com/hc/en-us/community/posts/… worked for me.

[user1894292]

Me too. Thanks @gMale

[Dallin]

I had this turned on and was still seeing the problem described. Turning it off and back on again fixed it.