Fix typos

CONTRIBUTING.md

@@ -69,14 +69,14 @@ GIT_USER=<your-github-username> CURRENT_BRANCH=gh-pages USE_SSH=true npm run pub
 Releasing versions is the responsibility of the core maintainers. Most people
 can skip this section.
 
-Twirp uses Github releases. To make a new release:
+Twirp uses GitHub releases. To make a new release:
 
 1.  Merge all changes that should be included in the release into the main branch.
 2.  Update the version constant in `internal/gen/version.go`. Please respect [semantic versioning](http://semver.org/): `v<major>.<minor>.<patch>`.
 3.  Run `make test_all` to re-generate code and run tests. Check that generated test files include the new version in the header comment.
 4.  Add a new commit to main with a message like "Version vX.X.X release" and push.
 5.  Tag the commit you just made: `git tag vX.X.X` and `git push origin --tags`.
-6.  Go to Github https://github.com/twitchtv/twirp/releases and "Draft a new release".
+6.  Go to GitHub https://github.com/twitchtv/twirp/releases and "Draft a new release".
 7.  Make sure that all new functionality is properly documented, on code comments, PR description, and include links and/or upgrade instructions on the release. For example the [v7 release](https://github.com/twitchtv/twirp/releases/tag/v7.0.0). Minor releases can just include a link to the PR/PRs that were merged included into the release.
 
 ## Code of Conduct

README.md

@@ -60,7 +60,7 @@ Gopher slack [here](https://invite.slack.golangbridge.org/).
 
 ### Releases
 
-Twirp follows semantic versioning through git tags, and uses Github Releases for
+Twirp follows semantic versioning through git tags, and uses GitHub Releases for
 release notes and upgrade guides:
 [Twirp Releases](https://github.com/twitchtv/twirp/releases)
 

client_options.go

@@ -38,7 +38,7 @@ func WithClientInterceptors(interceptors ...Interceptor) ClientOption {
 // WithClientPathPrefix specifies a different prefix to use for routing.
 // If not specified, the "/twirp" prefix is used by default.
 // The service must be configured to serve on the same prefix.
-// An empty value "" can be speficied to use no prefix.
+// An empty value "" can be specified to use no prefix.
 // URL format: "<baseURL>[<prefix>]/<package>.<Service>/<Method>"
 // More info on Twirp docs: https://twitchtv.github.io/twirp/docs/routing.html
 func WithClientPathPrefix(prefix string) ClientOption {

docs/migrate_to_twirp.md

@@ -17,5 +17,5 @@ The process is a case-by-case scenario, but we can highlight a few common steps:
 3.  If the API is too big, it may be better to only migrate a few endpoints first. Protobuf schemas are good at evolving over time, you can always complete the migration for a few endpoints and add more endpoints later.
 4.  Generate code and implement your new API methods. You may be able to re-use some of the older code from the previous endpoints. One way to do this is to implement the new service in a subfolder inside the same project, and then mount the new Twirp handler in a sub-route (see [Muxing Twirp with other services](mux.md)).
 5.  Make sure to track stats about API endpoint usage, so you can see the traffic being migrated to the new endpoints. Use [hooks, interceptors](hooks.md) and/or HTTP [middleware](mux.md) as needed.
-6.  When the new Twirp service is ready, the API callers (upstream services) need to import the new Twirp client and update their calls to use the new Twirp API. This is why making the new API similar to the old one is useful. Some services may be able to just replace the old client with the new one and start sending traffic to the new endpoints, relying on their staging/canary environment for testing. Other services may want to implement a rollout slider to migrate traffic slowly (10%, 50%, etc.). The slider can be implemented in different ways. Here's a very naive implememtation in Go to allow 10% traffic on the new client: `if r.Intn(100) < 10 { callNewClient() } else { callOldClient() }`. In more complex cases, it is also possible to make client that implements the same Twirp service interface, but with options to split the traffic between the new API and the old API.
+6.  When the new Twirp service is ready, the API callers (upstream services) need to import the new Twirp client and update their calls to use the new Twirp API. This is why making the new API similar to the old one is useful. Some services may be able to just replace the old client with the new one and start sending traffic to the new endpoints, relying on their staging/canary environment for testing. Other services may want to implement a rollout slider to migrate traffic slowly (10%, 50%, etc.). The slider can be implemented in different ways. Here's a very naive implementation in Go to allow 10% traffic on the new client: `if r.Intn(100) < 10 { callNewClient() } else { callOldClient() }`. In more complex cases, it is also possible to make client that implements the same Twirp service interface, but with options to split the traffic between the new API and the old API.
 7.  When all traffic is migrated, don't forget to clean up the old code. If the old API is impossible to remove completely, it may be useful to re-implement old endpoints as shim calls to the new Twirp endpoints.

errors_test.go

@@ -158,11 +158,11 @@ func TestInternalErrorWith_Unwrap(t *testing.T) {
 	}
 }
 
-type errorResponeWriter struct {
+type errorResponseWriter struct {
 	*httptest.ResponseRecorder
 }
 
-func (errorResponeWriter) Write([]byte) (int, error) {
+func (errorResponseWriter) Write([]byte) (int, error) {
 	return 0, errors.New("this is only a test")
 }
 
@@ -204,7 +204,7 @@ func TestWriteError(t *testing.T) {
 		return
 	}
 
-	errResp := &errorResponeWriter{ResponseRecorder: resp}
+	errResp := &errorResponseWriter{ResponseRecorder: resp}
 
 	// Writing again should error out as headers are being rewritten
 	err = twirp.WriteError(errResp, twerr)

internal/gen/typemap/typemap.go

@@ -98,7 +98,7 @@ type MessageDefinition struct {
 	// publicly imported, what File was that import performed in?
 	File *descriptor.FileDescriptorProto
 	// Parent is the parent message, if this was defined as a nested message. If
-	// this was defiend at the top level, parent is nil.
+	// this was defined at the top level, parent is nil.
 	Parent *MessageDefinition
 	// Comments describes the comments surrounding a message's definition. If it
 	// was publicly imported, then these comments are from the actual source file,

internal/twirptest/client_test.go

@@ -394,7 +394,7 @@ func TestClientContextToHook(t *testing.T) {
 	}
 
 	if !requestCalled {
-		t.Error("misssing RequestPrepared hook call")
+		t.Error("missing RequestPrepared hook call")
 	}
 	if !responseCalled {
 		t.Error("missing ResponseReceived hook call")

internal/twirptest/service_test.go

@@ -1621,7 +1621,7 @@ func TestRequestBodyError(t *testing.T) {
 	}
 	for _, tc := range testCases {
 		t.Run(tc.testname, func(t *testing.T) {
-			// test case validate reqest body read error handling
+			// test case validate request body read error handling
 			var s Haberdasher
 			hooks := &twirp.ServerHooks{Error: func(ctx context.Context, err twirp.Error) context.Context {
 				if ctxErr := tc.expectedError; err.Code() != ctxErr {

server_options.go

@@ -36,7 +36,7 @@ func WithServerInterceptors(interceptors ...Interceptor) ServerOption {
 
 // WithServerPathPrefix specifies a different prefix for routing.
 // If not specified, the "/twirp" prefix is used by default.
-// An empty value "" can be speficied to use no prefix.
+// An empty value "" can be specified to use no prefix.
 // The clients must be configured to send requests using the same prefix.
 // URL format: "<baseURL>[<prefix>]/<package>.<Service>/<Method>"
 // More info on Twirp docs: https://twitchtv.github.io/twirp/docs/routing.html