Replace old references to "language-server" directory with "language".

hugo/content/docs/configuration-services.md

@@ -21,7 +21,7 @@ The *language specific services* are services specific to one Langium language a
 * Utility services (e.g. `References`, `JsonSerializer`)
 
 ## Customization
-If you have used the [Yeoman generator](https://www.npmjs.com/package/generator-langium), the entry point to services customization is found in the `src/language-server/...-module.ts` file, where '...' is the name of your language. There you can register new services or override the default implementations of services. Langium implements the *Inversion of Control* principle via the *Dependency Injection* pattern, which promotes loosely-coupled architectures, maintainability, and extensibility.
+If you have used the [Yeoman generator](https://www.npmjs.com/package/generator-langium), the entry point to services customization is found in the `src/language/...-module.ts` file, where '...' is the name of your language. There you can register new services or override the default implementations of services. Langium implements the *Inversion of Control* principle via the *Dependency Injection* pattern, which promotes loosely-coupled architectures, maintainability, and extensibility.
 
 For the following sections, we will use the [arithmetics example](https://github.com/eclipse-langium/langium/tree/main/examples/arithmetics) to describe the procedure for replacing or adding services. Note that all names prefixed with *Arithmetics* should be understood as being specific to the language named *Arithmetics*, and in your project those services' names will be prefixed with your own language name.
 

hugo/content/guides/builtin-library.md

@@ -94,7 +94,7 @@ To fix this issue, we need to implement a custom `FileSystemProvider` on the cli
 
 ```ts
 import * as vscode from 'vscode';
-import { builtinHelloWorld } from './language-server/builtins';
+import { builtinHelloWorld } from './language/builtins';
 
 export class DslLibraryFileSystemProvider implements vscode.FileSystemProvider {
 

hugo/content/tutorials/generation.md

@@ -17,7 +17,7 @@ To write the generator, we're going to work in the **src/cli/generator.ts** file
 
 ```ts
 // import the 'Model' type from our semantic model
-import { Model } from '../language-server/generated/ast.ts';
+import { Model } from '../language/generated/ast.ts';
 
 export function generateCommands(mode: Model, filePath: string, destination: string | undefined): string {
     // ...
@@ -84,7 +84,7 @@ Now, let's expand on `generateStatements`. From our grammar, there are 5 types o
 We we want to expand our function to handle each of these cases. This is easy to do using some special `isTYPE` functions made available from our semantic model. These are automatically generated from our grammar, and allow us to verify the type of a node from our AST at runtime.
 
 ```ts
-import { isPen, isMove, isMacro, isFor, isColor } from '../language-server/generated/ast';
+import { isPen, isMove, isMacro, isFor, isColor } from '../language/generated/ast';
 
 ...
 

hugo/content/tutorials/generation_in_the_web.md

@@ -65,8 +65,8 @@ Once we have this function in place, we can create our `parseAndGenerate` functi
 
 ```ts
 import { EmptyFileSystem } from "langium";
-import { createHelloWorldServices } from '../language-server/hello-world-module';
-import { Model } from "../language-server/generated/ast";
+import { createHelloWorldServices } from '../language/hello-world-module';
+import { Model } from "../language/generated/ast";
 import { generateCommands } from '../generator/generator';
 
 /**
@@ -134,7 +134,7 @@ Now the generator is cleanly separated from our CLI, and thus from our file syst
 
 ## Adding a Custom LSP Command Handler to Langium
 
-To add a custom command handler, start by modifying the existing module file for our language. For MiniLogo, this is located in **src/language-server/minilogo-module.ts**. In this file we can add our custom command handler as a special class:
+To add a custom command handler, start by modifying the existing module file for our language. For MiniLogo, this is located in **src/language/minilogo-module.ts**. In this file we can add our custom command handler as a special class:
 
 ```typescript
 import { AbstractExecuteCommandHandler, ExecuteCommandAcceptor } from 'langium';

hugo/content/tutorials/langium_and_monaco.md

@@ -24,7 +24,7 @@ Once you have a language picked, you're going to want to add a script to your **
 ```json
 {
     ...
-    "build:worker": "esbuild --minify ./out/language-server/main.js --bundle --format=iife --outfile=./public/minilogo-server-worker.js"
+    "build:worker": "esbuild --minify ./out/language/main.js --bundle --format=iife --outfile=./public/minilogo-server-worker.js"
 }
 ```
 
@@ -36,7 +36,7 @@ This makes sense since we're bundling for the web, and we can't depend on packag
 
 ## Factoring out File System Dependencies
 
-First off, let's create a new entry point for our language server in **src/language-server/main-browser.ts**. This will mirror the regular entry point that we use to build already, but will allow us to target a web-based context instead. In this file, we'll have the following contents:
+First off, let's create a new entry point for our language server in **src/language/main-browser.ts**. This will mirror the regular entry point that we use to build already, but will allow us to target a web-based context instead. In this file, we'll have the following contents:
 
 ```ts
 import { startLanguageServer, EmptyFileSystem } from 'langium';
@@ -78,7 +78,7 @@ Going back to the script we wrote before in our **package.json**, we're now read
 ```json
 {
     ...
-    "build:worker": "esbuild --minify ./out/language-server/main-browser.js --bundle --format=iife --outfile=./public/minilogo-server-worker.js"
+    "build:worker": "esbuild --minify ./out/language/main-browser.js --bundle --format=iife --outfile=./public/minilogo-server-worker.js"
 }
 ```
 

hugo/content/tutorials/validation.md

@@ -21,7 +21,7 @@ In this example we're going to *disallow* names that are non-unique for definiti
 
 ## The Validation Registry
 
-In order to express these constraints, we need to modify our language's **validator**. By default, this can be found in **src/language-server/YOUR-LANGUAGE-validator.ts**; with a name that corresponds to your language. This file begins with a validation registry that extends the default validation registry. The validation registry allows us to register validation checks for our language.
+In order to express these constraints, we need to modify our language's **validator**. By default, this can be found in **src/language/YOUR-LANGUAGE-validator.ts**; with a name that corresponds to your language. This file begins with a validation registry that extends the default validation registry. The validation registry allows us to register validation checks for our language.
 
 The constructor for the registry is of particular interest, as it allows associating validation functions with *specific* nodes in your AST. Here you can see an example of the constructor below for the default hello world language from the yeoman generator.
 
@@ -60,7 +60,7 @@ With this in mind, we can look back at our grammar that we've written for MiniLo
 - Validate that definitions have unique names in a Model
 - Validate that arguments have unique names in a Definition
 
-In order to perform a validation, we need to know the type of that node to validate. Beyond checking our grammar to find this, we can also check the semantic model (akin to the abstract syntax) of our language. This was generated while running `npm run langium:generate`, and is located in **src/language-server/generated/ast.ts**. Peeking into this model, we can see that our rule for `Model` was written like so:
+In order to perform a validation, we need to know the type of that node to validate. Beyond checking our grammar to find this, we can also check the semantic model (akin to the abstract syntax) of our language. This was generated while running `npm run langium:generate`, and is located in **src/language/generated/ast.ts**. Peeking into this model, we can see that our rule for `Model` was written like so:
 
 ```langium
 entry Model: (stmts+=Stmt | defs+=Def)*;

hugo/content/tutorials/writing_a_grammar.md

@@ -36,7 +36,7 @@ Now that we have an idea of our semantics and our concrete syntax, we can then s
 
 As an aside, our version of MiniLogo will be an *approximation* of Dr. Walkingshaw's version. We won't adhere to it completely, and we won't be incorporating some elements, such as variable declarations.
 
-To get started sketching the grammar we'll be using the **Hello World** example from the yeoman generator. You can read about how to get this setup in the [Getting Started](/docs/getting-started/) section of our docs. We'll be working with a fresh from the generator using only the defaults, and building up from that. We'll begin by modifying the default grammar file, and updating it to work for MiniLogo. You can find this file under **src/language-server/hello-world.langium** in your new project. If you used a name other than the default, the file will still be there, but using your custom name instead.
+To get started sketching the grammar we'll be using the **Hello World** example from the yeoman generator. You can read about how to get this setup in the [Getting Started](/docs/getting-started/) section of our docs. We'll be working with a fresh from the generator using only the defaults, and building up from that. We'll begin by modifying the default grammar file, and updating it to work for MiniLogo. You can find this file under **src/language/hello-world.langium** in your new project. If you used a name other than the default, the file will still be there, but using your custom name instead.
 
 We'll be overriding the existing langium grammar file completely, so delete the old contents before we begin.