Remove remaining references to vendor

.golangci.yml

@@ -1,7 +1,4 @@
 run:
-    skip-dirs:
-        - vendor
-
     timeout: 2m
 
 linters-settings:

Documentation/api.md

@@ -41,8 +41,6 @@ $ protoc --go_out=import_path=dexapi:. api.proto
 
 Client programs can then be written using the generated code. A Go client which uses dex's internally generated code might look like the following:
 
-__NOTE:__ Because dex has the `google.golang.org/grpc` package in its `vendor` directory, gRPC code in `github.com/dexidp/dex/api` refers to the vendored copy, not copies in a developers GOPATH. Clients must either regenerate the gRPC Go code or vendor dex and remove its `vendor` directory to run this program.
-
 ```
 package main
 

Documentation/dev-dependencies.md

@@ -2,7 +2,7 @@
 
 ## Go modules
 
-Dex uses [Go modules][go-modules] to manage its [`vendor` directory][go-vendor]. Go 1.11 or higher is recommended. While Go 1.12 is expected to finalize the Go modules feature, with Go 1.11 you should [activate the Go modules feature][go-modules-activate] before interacting with Go modules.
+Dex uses [Go modules][go-modules] to manage its dependencies. Go 1.11 or higher is recommended. While Go 1.12 is expected to finalize the Go modules feature, with Go 1.11 you should [activate the Go modules feature][go-modules-activate] before interacting with Go modules.
 
 Here is one way to activate the Go modules feature with Go 1.11.
 
@@ -21,22 +21,9 @@ To add a new dependency to dex or update an existing one:
   * Run `go mod tidy -v`. This is a good option if you do not wish to immediately pin to a specific Semantic Version or commit.
   * Run, for example, `go get <package-name>@<commit-hash>`. This is a good option when you want to immediately pin to a specific Semantic Version or commit.
   * Manually update `go.mod`.  If one of the two options above doesn't suit you, do this -- but very carefully.
-3. Create a git commit to reflect your code (not vendor) changes. See below for tips on composing commits.
+3. Create a git commit to reflect your code changes.
-4. Once `go.mod` describes the desired state and you've create a commit for that change, run `make revendor` to update `go.mod`, `go.sum` and `vendor`. This calls `go mod tidy -v`, `go mod vendor -v` and `go mod verify`.
-5. Create a git commit to reflect the changes made by `make revendor`. Again, see below for tips on composing commits.
 
-## Composing commits
-
-When composing commits make sure that updates to `vendor` are in a separate commit from the main changes. GitHub's UI makes commits with a large number of changes unreviewable.
-
-Commit histories should look like the following:
-
-```
-connector/ldap: add a LDAP connector
-vendor: revendor
-```
 
 [go-modules]: https://github.com/golang/go/wiki/Modules
 [go-modules-activate]: https://github.com/golang/go/wiki/Modules#how-to-install-and-activate-module-support
-[go-vendor]: https://golang.org/cmd/go/#hdr-Vendor_Directories
 [module-aware-go-get]: https://tip.golang.org/cmd/go/#hdr-Module_aware_go_get

vendor.go

@@ -1,14 +0,0 @@
-// +build vendor
-
-package main
-
-// This file exists to trick "go mod vendor" to include "main" packages.
-// It is not expected to build, the build tag above is only to prevent this
-// file from being included in builds.
-
-import (
-        _ "github.com/golang/protobuf/protoc-gen-go"
-        _ "golang.org/x/lint/golint"
-)
-
-func main() {}