vgo integration support

Posted on by Florin Pățan

Package management has long been a topic of interest for many people in the Go community. A few months ago, the Go team put forward a new tool, based on the learnings from dep and other package managers. This tool is called vgo, and it’s backed by a new dependency solving algorithm called Minimal Version Selection, or MVS. All of this is described in great detail in Russ Cox’s blog post series.

Given the importance of this tool, it’s easy to see how the request to integrate it with the IDE quickly became one of the most voted features.

Today we are happy to announce the first version this integration is available as a plugin for GoLand 2018.1.2+. This feature will be integrated by default in the upcoming 2018.2 release.

Before you head over to Settings | Plugins | Install JetBrains plugin… and download the vgo support plugin, let’s see what it can do.

To create a project using vgo, you need to select the vgo type in the New Project dialog and then make sure that the IDE detected the vgo location correctly, after that, a new project will be created with the boilerplate go.mod file being created for it.

vgo - create new project

Now, let’s create a simple web server which will have a dependency. To do so, we’ll use the popular gorilla/mux package, and the following code:

package main

import ""

func main() {
	r := mux.NewRouter()
	_ = r

The IDE will notice that there is no gorilla/mux currently defined in the go.mod file and it will suggest running the required vgo operation to update your dependencies list.

vgo - add new dependency

Similarly, if you remove a dependency from the go.mod file, the IDE will automatically remove the dependency from the list of available libraries, all seamlessly integrated into the workflow.

vgo - remove dependency

This is an early release of the plugin that we want to share with you. As such, it does have a few of issues of its own, not related to vgo itself.
Perhaps the one that you will first notice is that the IDE won’t allow you to use the vgo list quick fix if the package is already present in the GOPATH. This is a known limitation, and the recommendation is to set your GOPATH to point to somewhere else in the system, vgo still needs it to download and store the package cache. Another way to solve this is to remove the package from your GOPATH, but you will need to also invalidate the IDE cache. Please watch GO-5701 for updates on this issue.
The second issue is that currently the go.mod functionality is minimal, but we have plans to change this, GO-5691.
Another issue is that the “replace” syntax is currently not recognized by the IDE so forks or other sources for the packages will not work, see GO-5702 for more information.

And that’s it for now. Keep in mind that currently vgo is in very early stages and you are likely to encounter some rough edges. If you do so, please report them to us so we can address them or inform the Go team about them.

Please let us know in the comments below or on our issue tracker if you have any suggestions or feedback, or what would you like to see next. And remember, the 2018.2 EAP is right around the corner with a lot of new things to come.

Comments below can no longer be edited.

14 Responses to vgo integration support

  1. Andy says:

    May 18, 2018

    Hi! How to change DEP project to VGO project?

    • lin says:

      May 19, 2018

      create new project ,copy and paste, lol

    • Florin Pățan says:

      May 25, 2018

      Here’s an example directly from the Go team on how to do this migration: If you have any further questions, feel free to ping us. Additionally, you can join the Gophers Slack,, which has a dedicated vgo channel, and you can get help from other users in real-time.

      Hope this helps.

  2. JtL says:

    May 23, 2018

    Andy, what I did for one of my test projects, was to disable Dep and enable Vgo from IDE settings (checkbox and specify path to the Vgo).

    Then running the project lead to VGO error described at (i.e. yet not recognized Gopkg.lock file).

    So, I had to remove that file (which might not what you like to do).

    Next error, I’ve got was about missing go.mod file. I’ve created one with single line inside:


    Next, running the project was successful. The go.mod was filled with lines like this:

    require v0.8.0

    Hope that helps

  3. Bruno says:

    June 21, 2018

    I’m trying this with IntelliJ 2018.2 EAP. I’ve enabled vgo support, it found my vgo binary. I created a vgo project. It created the boilerplate go.mod. I created a go file, with the exact code as above. I told IntelliJ to add the dependency, exactly like in the gif above. Vgo properly downloads and installs gorilla mux.

    But IntelliJ doesn’t add the vgo dependencies to the “External Dependencies”, and it still complains about the import, saying that it cannot resolve it.

    Am I missing something? Or is this just not working yet in IntelliJ 2018.2 EAP?


    • Florin Pățan says:

      June 21, 2018

      Hi Bruno,

      Recently vgo changed a few things on how it works upon which our IDE relies on.
      We are working to get this working again, see and

      The only workaround that I can think of right now is using this version, which is before the changes happened, but doesn’t include some bug fixes.

      I’m sorry I don’t have better news for now. Thank you for your understanding and patience.

      • Bruno says:

        June 21, 2018

        Hi Florin,

        Thanks for your quick response!

        I actually came back here to say that I figured out what the issue was, by viewing exactly those two YouTrack issues 🙂

        Also, wanted to share the workaround I found. Instead of downgrading VGO so it would keep using the /v folder, what I did is to manually create the /v folder, and make /mod a symlink to /v.

        $ cd ~/go
        $ mv mod v
        $ ln -s v mod

        I had tried first to keep the real folder called /mod (as the recent vgo versions expect) and make /v a symlinkg pointing to /mod, but although IntelliJ could find the references, it was complaining about something like “no sources to compile”. After making the change above, IntelliJ is now happy, and vgo is also happy (ie, it works fine if /mod is a symlink, at least in my simple tests)!


        • yaniv says:

          July 2, 2018


          I tried your solution but it doesn’t work for me 🙁
          I even tried to duplicate the mod folder.

          • Florin Pățan says:

            July 2, 2018

            We fixed a number of issues to match the latest changes in vgo and these will make their way in the next EAP release, which should be here shortly. Hopefully, nothing else will break from vgo side until then. Sorry for the inconvenience caused.

      • yaniv says:

        July 2, 2018

        Hi Florin,

        Do you know where it will be release with fix for this issue?
        Meanwhile as work around as you suggested, where can I find older ego version (I couldn’t find any branches)?


        • Florin Pățan says:

          July 2, 2018

          I’m sorry, at the moment I don’t have a date yet, but the team is aware of this issue and is working on getting this out as quickly as possible.

          • yaniv says:

            July 3, 2018


            Thank you for the response, do you know where can I find an older ego version?


          • Florin Pățan says:

            July 3, 2018

            @yaniv you can checkout at an earlier version of the vgo repository and then run “go install” on it but this wouldn’t help to fix the issues in the current case, that’s why I did not recommend it to you so far. Please wait for the next EAP to get this sorted out. Thank you for your understanding.

  4. Что нового в GoLand 2018.2 - Новини дня says:

    August 2, 2018

    […] про про поддержку модулей Go можно прочитать здесь (статья на […]


Subscribe for updates