IntelliJ IDEA 2024.1 Help

Build constraints and vendoring

Build constraints and vendoring mode are tools you can use to fine-tune your build process. With build constraints, you define rules that determine which files are included in the package. By enabling vendoring mode, you ensure your application is built only with dependency packages stored within your project. This approach allows you to include a specific set of files in your package and use dependencies that you have locally modified or patched.

Build constraints

A build constraint, also known as a build tag, is a line comment that outlines the conditions under which a file is included in the package. These tags can specify requirements such as the operating system, architecture, Go version, compiler, cgo support, or other target system needs. In the example below, we declare that this file is for the target system meeting the following criteria:

  • //+build darwin,cgo linux is the older syntax for build tags, still recognized in Go. It specifies two sets of conditions:

    • darwin,cgo: Include in the build when compiling for the darwin platform (macOS) and when cgo is enabled. cgo enables the inclusion of C code in Go programs.

    • linux: Include when compiling for the Linux platform.

    The space acts as an OR operator, meaning the file should be included for macOS with cgo enabled or for Linux.

  • //go:build (darwin && cgo) || linux is the newer syntax for build tags, introduced in Go 1.17, using a more explicit boolean expression format:

    • (darwin && cgo) || linux: The file should be included in the build for macOS with cgo enabled or for Linux, identical to the above condition.

Build constraints

IntelliJ IDEA can use these constraints to decide what files must be ignored during validation, resolving, and symbol suggestions. If the file does not satisfy the requirements of the target system, IntelliJ IDEA displays a notification. For example, the following conditions on the screenshot will conflict with settings from the Configure build constraints for your project procedure.

Notification about build constraints

Configure build constraints for your project

Options that you define in settings describe your target system for the project.

  1. Open settings (Ctrl+Alt+S) and navigate to Languages & Frameworks | Go | Build tags.

  2. From drop-down lists, select expected values for the target system. If you have any custom tags, specify them in the Custom tags field (use a space between tags as a separator).

  3. Click OK.

    Configure build constraints for your project

Using Go experiments

  1. Open settings by pressing Ctrl+Alt+S and navigate to Go | Build Tags.

  2. Type tags for Go Experiments in one of the fields:

    • Custom tags: type tags in the following format: goexperiment.rangefunc goexperiment.loopvar. Use spaces to separate tags from each other.

    • Experiments: type tags in the following format: rangefunc,loopvar. Use commas to separate tags from each other.

    Tag names are located within the corresponding packages. For instance, upon accessing the iter package, you will notice the tag name directly following the go:build tag. Specifically for the iter package, the tag is goexperiment.rangefunc. In the Custom tags field, enter the complete tag, whereas in the Experiments field, input only the segment subsequent to goexperiment..

Description of Build Tags fields

For more information about build tags or constraints, see Build constraints at


Build Tags


Operating System


Specifies the operating system you're compiling your code for, such as linux or windows.



Defines the CPU architecture for your code, like amd64 or arm.

Go Version


Tells you the Go version installed. It is the same version you see when you run go version.


Chooses the compiler, like gccgo or gc, based on what is available in your runtime.

CGO Support


Shows if cgo is enabled (1) or disabled (0), affecting whether you can include C code.

Custom Tags

Any build tags introduced by the //go:build comment line.

For example, in the following screenshot, the goexperiment.rangefunc build tag enables iteration over a function from Go Experiments.



A list of Go toolchain experiments you can turn on or off. Mainly for developers working on Go itself.

Using multiple conditions for build constraints

Due to the introduction of a new syntax for build constraints, consider the following table that lists the differences between two syntaxes when using multiple conditions.



//+build darwin,cgo linux

A comma (as a logical And) and a whitespace (as a logical Or)

//go:build (darwin && cgo) || linux

The && operator (logical And) and the || operator (logical Or)


With the vendoring mode enabled, you build your application only with dependency packages that are stored inside your project under the vendor directory. In this mode, Go commands ignore dependency descriptions in go.mod and assume that the vendor directory holds the correct copies of dependencies. By default, when you use Go modules, the vendor directory is ignored during the build.

In Go 1.14 RC, automatic vendoring mode became a built-in Go feature. Starting from Go 1.14 RC, IntelliJ IDEA also enables automatic vendoring mode by default. You can disable vendoring per project, for example, when you have a monorepo containing the vendor folder used by another language.

You can control automatic vendoring by using the Enable vendoring support automatically checkbox. When the checkbox is selected, automatic vendoring is enabled. So, if you add the vendor directory to the module, the IDE uses it. If you remove the directory, IntelliJ IDEA uses the global Go Modules cache.

Toggle vendoring mode

  1. Open settings by pressing Ctrl+Alt+S and navigate to Languages & Frameworks | Go | Go Modules.

  2. Clear or select the Enable vendoring support automatically checkbox and click OK.

Last modified: 19 March 2024