Improve spell-checking (#7126)

Author: glen-84

.github/workflows/ci.yml

@@ -86,7 +86,7 @@ jobs:
         run: npm install -g cspell
 
       - name: run cspell
-        run: cspell --config ./cSpell.json "website/src/**/*.md" --no-progress --no-cache
+        run: cspell --config ./cspell.json "website/src/**/*.md" --no-progress --no-cache
 
   linting:
     name: "Markdown linting"

.vscode/extensions.json

@@ -5,6 +5,7 @@
     "EditorConfig.EditorConfig",
     "k--kato.docomment",
     "dbaeumer.vscode-eslint",
-    "josefpihrt-vscode.roslynator"
+    "josefpihrt-vscode.roslynator",
+    "streetsidesoftware.code-spell-checker"
   ]
 }

CONTRIBUTING.md

@@ -75,11 +75,11 @@ There are other available commands too. As set up in the [.build](./.build/) dir
 
 ## How to Check the docs
 
-We use [Markdownlint](https://github.com/DavidAnson/markdownlint) to check markdown formatting and [cSpell](https://cspell.org) for spelling. We have GitHub actions to check these for PRs, but if you'd like to check locally, you can:
+We use [Markdownlint](https://github.com/DavidAnson/markdownlint) to check markdown formatting and [CSpell](https://cspell.org) for spelling. We have GitHub actions to check these for PRs, but if you'd like to check locally, you can:
 
-- Install cSpell: `npm install -g cspell`
+- Install CSpell: `npm install --global cspell`
 - Install the markdownlint CLI: `npm install -g markdownlint-cli`.
-- For spellcheck, run `cspell --config ./cSpell.json "website/src/**/*.md" --no-progress`
+- For spellcheck, run `cspell --config ./cspell.json "website/src/**/*.md" --no-progress`
 - For markdown linting, run `markdownlint "./website/src/**/*.md" --disable MD013`
 
 ## Code of conduct

cSpell.json

@@ -0,0 +1,16 @@
+{
+  "$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json",
+  "version": "0.2",
+  "language": "en",
+  "dictionaries": ["csharp", "custom"],
+  "dictionaryDefinitions": [
+    {
+      "name": "custom",
+      "path": "./dictionary.txt"
+    }
+  ],
+  "ignoreRegExpList": [
+    "featuredVideoId:(.*)", // video hash
+    "videoId=\"(.*)\"" // video hash
+  ]
+}

cspell.json

@@ -0,0 +1,88 @@
+Andi
+aspnetcore
+automagically
+autonumber
+Badurina
+bananacakepop
+BCPROCKS
+blazor
+blazorwasm
+BSON
+cacheable
+CCPA
+chillicream
+Contoso
+CQRS
+dataloaders
+decompile
+enisdenjo
+entityframework
+FIPS
+foos
+fricking
+Giroux
+GraphiQL
+graphqlconfig
+graphqlrc
+graphyne
+greendonut
+Hasura
+hotchocolate
+Kellner
+Kydne
+Linq
+Marek
+matchesBrics
+mercurius
+meros
+ncontains
+nendsWith
+NEWHOPE
+Newtonsoft
+ngte
+nintersects
+nlte
+Noda
+Normen
+noverlaps
+Npgsql
+nstartsWith
+NSwag
+ntouches
+nwithin
+oneof
+OpenIddict
+OWIN
+pageable
+PKCE
+Postgraphile
+preconfigured
+protobuf
+quox
+quux
+Rafi
+reencode
+relayjs
+Rgba
+runbooks
+Senn
+shoooe
+Skywalker
+snapshooter
+Specwise
+srid
+Staib
+starwars
+strawberryshake
+Structs
+sublicensable
+supergraph
+Swashbuckle
+Tengler
+unpublish
+URQL
+vsix
+websockets
+winget
+Wunder
+xunit

dictionary.txt

@@ -27,7 +27,7 @@ We now are finished with implementing the query validation rules. The following
 - Directives Are Defined [124](https://github.com/ChilliCream/graphql-platform/issues/124)
 - Values of Correct Type [120](https://github.com/ChilliCream/graphql-platform/issues/120)
 
-We now also support the `@deprectaed` directive when using schema-first.
+We now also support the `@deprecated` directive when using schema-first.
 
 Furthermore, we fixed a lot of bugs around schema-first. So, at the moment code-first is still the most viable way to create a schema,but we are working hard to get both flavours on par.
 

website/src/blog/2018-09-02-hot-chocolate-0.4.5.md

@@ -925,7 +925,7 @@ type UserMutations {
 The stitching engine provides a lot of extension points, but if we wanted to write the stitching for one specific resolver by ourselves then we could do that by using the `IStitchingContext` which is a scoped service and can be resolved through the resolver context.
 
 ```csharp
-IStitchingContext stitchingContext = context.Service<IStichingContext>();
+IStitchingContext stitchingContext = context.Service<IStitchingContext>();
 IRemoteQueryClient remoteQueryClient = stitchingContext.GetRemoteQueryClient("messages");
 IExecutionResult result = remoteQueryClient.ExecuteAsync("{ foo { bar } }")
 ```

website/src/blog/2019-02-20-schema-stitching.md

@@ -116,7 +116,7 @@ The query executor will return an execution result, depending on the type of ope
 
 An `IReadOnlyQueryResult` contains basically the result graph of the query, but asserting this could be very tiresome.
 
-My good friend [Normen](https://github.com/nscheibe) who works at Swiss Life created a snapshot testing library that basically works like [jestjs](https://jestjs.io). We use _Snapshooter_ internally to test the Hot Chocolate core.
+My good friend [Normen](https://github.com/nscheibe) who works at Swiss Life created a snapshot testing library that basically works like [Jest](https://jestjs.io). We use _Snapshooter_ internally to test the Hot Chocolate core.
 
 [Snapshooter](https://github.com/SwissLife-OSS/snapshooter) will create a snapshot at the first execution of the test. The snapshots are saved in a folder `__snapshot__` that is co-located with our test class. Every consecutive test run will be validated against that first snapshot. If the snapshots do not match the test will fail and tell us what part did not match.
 

website/src/blog/2019-04-11-integration-tests.md

@@ -48,11 +48,11 @@ With our new schema builder, we did a lot of work underneath and introduced the
 
 **For what is that useful?**
 
-For one you can now register our new `INamingConverions` with the dependency injection and then the new `SchemaBuilder` will use your naming conventions instead of the built-in naming conventions.
+For one you can now register our new `INamingConventions` with the dependency injection and then the new `SchemaBuilder` will use your naming conventions instead of the built-in naming conventions.
 
 Also, you can register our new `ITypeInspector` and override how we infer schema types from POCOs. This will allow you for instance to add support for custom attributes, so no need to pollute your API with our attributes anymore.
 
-But fear not, you do not have to implement the whole `INamingConverions` interface for instance since you can override each part of our default implementation.
+But fear not, you do not have to implement the whole `INamingConventions` interface for instance since you can override each part of our default implementation.
 
 Since, in many cases we just want to tune existing naming conventions we can inherit from the default implementation `DefaultNamingConventions` and overwrite just what we want to change.
 
@@ -88,11 +88,11 @@ In order to register our conventions with the schema builder we can do the follo
 ```csharp
 public void ConfigureServices(IServiceCollection services)
 {
-    services.AddSingleton<INamingConverions, MyNamingConventions>();
+    services.AddSingleton<INamingConventions, MyNamingConventions>();
     services.AddGraphQL(sp => Schema.Create(c =>
     {
         c.RegisterServiceProvider(sp);
-        c.RegisterQuerType<Foo>();
+        c.RegisterQueryType<Foo>();
     }));
 
 }
@@ -103,7 +103,7 @@ Or we could do it like the following with the new schema builder:
 ```csharp
 public void ConfigureServices(IServiceCollection services)
 {
-    services.AddSingleton<INamingConverions, MyNamingConventions>();
+    services.AddSingleton<INamingConventions, MyNamingConventions>();
     services.AddGraphQL(sp => SchemaBuilder.New()
         .AddQueryType<Foo>()
         .AddServices(sp));