docs: fix broken links (#1734)

packages/website/docs/features/custom_errors.md

@@ -3,8 +3,8 @@
 Chevrotain allows users to customize both the parser and lexer error messages.
 This can be accomplished by implementing the following interfaces:
 
-- [IParserErrorMessageProvider](https://chevrotain.io/documentation/9_1_0/interfaces/iparsererrormessageprovider.html)
-- [ILexerErrorMessageProvider](https://chevrotain.io/documentation/9_1_0/interfaces/ilexererrormessageprovider.html)
+- [IParserErrorMessageProvider](https://chevrotain.io/documentation/9_1_0/interfaces/IParserErrorMessageProvider.html)
+- [ILexerErrorMessageProvider](https://chevrotain.io/documentation/9_1_0/interfaces/ILexerErrorMessageProvider.html)
 
 See executable examples:
 
@@ -25,7 +25,7 @@ $.RULE("myStatement", () => {
 
 The **ERR_MSG** config property is available for the following DSL methods:
 
-- [CONSUME](https://chevrotain.io/documentation/9_1_0/classes/cstparser.html#consume)
-- [OR](https://chevrotain.io/documentation/9_1_0/classes/cstparser.html#or)
-- [AT_LEAST_ONE](https://chevrotain.io/documentation/9_1_0/classes/cstparser.html#at_least_one)
-- [AT_LEAST_ONE_SEP](https://chevrotain.io/documentation/9_1_0/classes/cstparser.html#at_least_one_sep)
+- [CONSUME](https://chevrotain.io/documentation/9_1_0/classes/CstParser.html#CONSUME)
+- [OR](https://chevrotain.io/documentation/9_1_0/classes/CstParser.html#OR)
+- [AT_LEAST_ONE](https://chevrotain.io/documentation/9_1_0/classes/CstParser.html#AT_LEAST_ONE)
+- [AT_LEAST_ONE_SEP](https://chevrotain.io/documentation/9_1_0/classes/CstParser.html#AT_LEAST_ONE_SEP)

packages/website/docs/features/gates.md

@@ -20,7 +20,7 @@ $.RULE("Value", (isConst) => {
 })
 ```
 
-Using the [Look Ahead](https://chevrotain.io/documentation/9_1_0/classes/cstparser.html#la) method is often helpful with the use of Gates to determine if a path should be followed or not, for example:
+Using the [Look Ahead](https://chevrotain.io/documentation/9_1_0/classes/CstParser.html#LA) method is often helpful with the use of Gates to determine if a path should be followed or not, for example:
 
 ```javascript
 // SELECT LIMIT.ID FROM USER_LIMIT LIMIT

packages/website/docs/features/grammar_inheritance.md

@@ -4,8 +4,8 @@ Chevrotain supports Grammar Inheritance, This is useful to represent multiple va
 for example a grammar for ECMAScript 6 **extends** an ECMAScript 5.1 grammar.
 
 Chevrotain Grammars are JavaScript classes, so Grammar inheritance is simply JavaScript inheritance
-with the replacement of the [**RULE**](https://chevrotain.io/documentation/9_1_0/classes/cstparser.html#rule)
-DSL method with [**OVERRIDE_RULE**](https://chevrotain.io/documentation/9_1_0/classes/cstparser.html#override_rule) method when needed.
+with the replacement of the [**RULE**](https://chevrotain.io/documentation/9_1_0/classes/CstParser.html#RULE)
+DSL method with [**OVERRIDE_RULE**](https://chevrotain.io/documentation/9_1_0/classes/CstParser.html#OVERRIDE_RULE) method when needed.
 
 See [executable example](https://github.com/chevrotain/chevrotain/tree/master/examples/parser/inheritance)
 for further details.

packages/website/docs/features/position_tracking.md

@@ -10,7 +10,7 @@ token_skipping
 - start and end lines.
 - start and end columns.
 
-The level of position information tracking can be reduced by using the [**positionTracking**](https://chevrotain.io/documentation/9_1_0/interfaces/ilexerconfig.html#positiontracking) lexer config option.
+The level of position information tracking can be reduced by using the [**positionTracking**](https://chevrotain.io/documentation/9_1_0/interfaces/ILexerConfig.html#positionTracking) lexer config option.
 For example:
 
 ```javascript

packages/website/docs/features/token_grouping.md

@@ -3,7 +3,7 @@
 Chevrotain lexers support grouping Tokens Types **separately** from the main token vector in the lexing result.
 This is often useful to **collect** a specific set of Token Types for later processing, for example to collect comments tokens.
 
-To group a Token Type simply specify the [**group**](https://chevrotain.io/documentation/9_1_0/interfaces/itokenconfig.html#group) property in its configuration.
+To group a Token Type simply specify the [**group**](https://chevrotain.io/documentation/9_1_0/interfaces/ITokenConfig.html#group) property in its configuration.
 For example:
 
 ```javascript

packages/website/docs/guide/concrete_syntax_tree.md

@@ -27,7 +27,7 @@ There are two major differences.
 
 How to enable CST output?
 
-This feature is enabled when a parser extends the [CstParser class](https://chevrotain.io/documentation/9_1_0/classes/cstparser.html).
+This feature is enabled when a parser extends the [CstParser class](https://chevrotain.io/documentation/9_1_0/classes/CstParser.html).
 
 ```typescript
 import { CstParser } from "chevrotain"
@@ -43,7 +43,7 @@ class SelectParser extends CstParser {
 
 The structure of the CST is very simple.
 
-- See the full [CstNode type signature](https://chevrotain.io/documentation/9_1_0/interfaces/cstnode.html)
+- See the full [CstNode type signature](https://chevrotain.io/documentation/9_1_0/interfaces/CstNode.html)
 
 - Explore it by running the CST creation example in the [**online playground**](https://chevrotain.io/playground/?example=JSON%20grammar%20and%20automatic%20CST%20output).
 
@@ -236,7 +236,7 @@ as we would have to fully traverse a CstNode to understands its full location ra
 
 The feature for providing CstNode location directly on the CstNodes objects is available since version 4.7.0.
 Tracking the CstNodes location is **disabled by default** and can be enabled
-by setting the IParserConfig [nodeLocationTracking](https://chevrotain.io/documentation/9_1_0/interfaces/iparserconfig.html#nodelocationtracking)
+by setting the IParserConfig [nodeLocationTracking](https://chevrotain.io/documentation/9_1_0/interfaces/IParserConfig.html#nodeLocationTracking)
 to:
 
 - "full" (start/end for **all** offset/line/column)
@@ -256,14 +256,14 @@ class SelectParser extends CstParser {
 }
 ```
 
-Once this feature is enabled the optional [location property](https://chevrotain.io/documentation/9_1_0/interfaces/cstnode.html#location)
+Once this feature is enabled the optional [location property](https://chevrotain.io/documentation/9_1_0/interfaces/CstNode.html#location)
 on each CstNode would be populated with the relevant information.
 
 Caveats
 
 - In order to track the CstNodes location **every** Token in the input Token vector must include its own location information.
 
-  - This is enabled by default in the Chevrotain Lexer, See [ILexerConfig.positionTracking](https://chevrotain.io/documentation/9_1_0/interfaces/ilexerconfig.html#positiontracking).
+  - This is enabled by default in the Chevrotain Lexer, See [ILexerConfig.positionTracking](https://chevrotain.io/documentation/9_1_0/interfaces/ILexerConfig.html#positionTracking).
     However, if a third party Lexer is used in conjunction with a Chevrotain Parser, the Tokens produced by such a lexer
     must include the relevant location properties to allow the chevrotain parser to compute the CstNode locations.
 

packages/website/docs/guide/initialization_performance.md

@@ -7,7 +7,7 @@ In some use cases this overhead may need to be reduced as much as possible.
 ## Enabling Initialization Performance Tracing
 
 Measuring a Parser's initialization performance can be done by enabling the
-[`IParserConfig.traceInitPerf`](https://chevrotain.io/documentation/9_1_0/interfaces/iparserconfig.html#traceinitperf)
+[`IParserConfig.traceInitPerf`](https://chevrotain.io/documentation/9_1_0/interfaces/IParserConfig.html#traceInitPerf)
 flag. For example:
 
 ```javascript
@@ -26,7 +26,7 @@ new InitTracingParser() // Will print tracing info to the console.
 ```
 
 A Lexer's initialization performance can similarly be measured by enabling the
-[`ILexerConfig.traceInitPerf`](https://chevrotain.io/documentation/9_1_0/interfaces/ilexerconfig.html#traceinitperf)
+[`ILexerConfig.traceInitPerf`](https://chevrotain.io/documentation/9_1_0/interfaces/ILexerConfig.html#traceInitPerf)
 flag:
 
 ```javascript
@@ -43,7 +43,7 @@ Chevrotain is a K tokens lookahead Parser, this means it peeks ahead (at most) K
 determine the alternative to pick whenever it encounters a "branching" in the grammar.
 
 During initialization Chevrotain pre-computes and caches lookahead functions that would
-later be used at runtime. The global [maxLookahead](https://chevrotain.io/documentation/9_1_0/interfaces/iparserconfig.html#maxlookahead)
+later be used at runtime. The global [maxLookahead](https://chevrotain.io/documentation/9_1_0/interfaces/IParserConfig.html#maxLookAhead)
 setting can significantly affect the performance of this pre-computation due to the fact the number of possible "paths"
 in the grammar can grow **exponentially** as the max length of the possible paths increases.
 
@@ -103,7 +103,7 @@ class LowLookaheadParser extends CstParser {
 Chevrotain performs many validations during Lexer & Parser initialization, however those are not really relevant
 when the Lexer & Parser are known to be valid, These validations are a **development time** tool, and not really needed during productive flows.
 
-The [IParserConfig.skipValidations](https://chevrotain.io/documentation/9_1_0/interfaces/iparserconfig.html#skipvalidations)
+The [IParserConfig.skipValidations](https://chevrotain.io/documentation/9_1_0/interfaces/IParserConfig.html#skipValidations)
 config property can be used to avoid running these validations during **Parser** initialization.
 
 ```javascript
@@ -119,7 +119,7 @@ class NaiveSkippedValidationsParser extends CstParser {
 }
 ```
 
-Similarly the [ILexerConfig.skipValidations](https://chevrotain.io/documentation/9_1_0/interfaces/ilexerconfig.html#skipvalidations)
+Similarly the [ILexerConfig.skipValidations](https://chevrotain.io/documentation/9_1_0/interfaces/ILexerConfig.html#skipValidations)
 config property can be used to skip the optional validations during **Lexer** initialization.
 
 ```javascript

packages/website/docs/guide/internals.md

@@ -8,7 +8,7 @@ and at some point understand the implementation details may become necessary.
 #### TLDR
 
 Wrap any semantic actions that cause runtime errors during the recording phase
-or have global side effects with the [ACTION DSL method](https://chevrotain.io/documentation/9_1_0/classes/baseparser.html#action) to
+or have global side effects with the [ACTION DSL method](https://chevrotain.io/documentation/9_1_0/classes/BaseParser.html#ACTION) to
 resolve issues.
 
 ### The Problem
@@ -40,7 +40,7 @@ $.RULE("value", () => {
 
 Chevrotain solves the problem of "understanding" the grammar structure by running the Parser in a "Recording Mode"
 with **alternative implementations** of the parsing methods (OR/MANY/OPTION/...), the results of these "recordings" are saved
-on the Parser instance and are accessible via the [getGastProductions](https://chevrotain.io/documentation/9_1_0/classes/baseparser.html#getgastproductions)
+on the Parser instance and are accessible via the [getGastProductions](https://chevrotain.io/documentation/9_1_0/classes/BaseParser.html#getGAstProductions)
 method. However for this to work successfully there are a couple of implicit assumptions..
 
 ### Assumption 1 - The Parser won't throw errors during recording.
@@ -163,7 +163,7 @@ class JsonParser extends CstParser {
 #### The Solution
 
 The solution is to simply **avoid executing any code that could raise such exceptions during the recording phase**.
-This can be easily accomplished by wrapping the relevant semantic actions with the [ACTION DSL method](https://chevrotain.io/documentation/9_1_0/classes/baseparser.html#action)
+This can be easily accomplished by wrapping the relevant semantic actions with the [ACTION DSL method](https://chevrotain.io/documentation/9_1_0/classes/BaseParser.html#ACTION)
 for example lets resolve the two scenarios shown above:
 
 ```javascript
@@ -256,7 +256,7 @@ console.log(counter) // -> 1
 #### Solutions
 
 As before one of the solutions will be to wrap the relevant embedded semantic action using the
-[ACTION DSL method](https://chevrotain.io/documentation/9_1_0/classes/baseparser.html#action).
+[ACTION DSL method](https://chevrotain.io/documentation/9_1_0/classes/BaseParser.html#ACTION).
 This is normally most suitable for handling **global state** outside the Parser's instance.
 
 ```javascript
@@ -270,7 +270,7 @@ $.RULE("myRule", () => {
 ```
 
 Because we are dealing with state here there is another option which is to override the Parser's
-[reset method](https://chevrotain.io/documentation/9_1_0/classes/parser.html#reset).
+[reset method](https://chevrotain.io/documentation/9_1_0/classes/CstParser.html#reset).
 This is normally suitable for state that needs to be reset every time **new input** provided to the parser.
 
 ```javascript
@@ -302,4 +302,4 @@ Due to the execution of the Parser rules during the "recording phase".
 Some break points inside Chevrotain Parsers will be hit during the Parser's initialization.
 
 It is possible to workaround this issue by using **conditional breakpoints** that inspect that the
-[RECORDING_PHASE flag](https://chevrotain.io/documentation/9_1_0/classes/baseparser.html#recording_phase) is disabled.
+[RECORDING_PHASE flag](https://chevrotain.io/documentation/9_1_0/classes/BaseParser.html#RECORDING_PHASE) is disabled.

packages/website/docs/guide/performance.md

@@ -29,7 +29,7 @@ Avoiding the creation of new instances is important to avoid re-paying the Parse
 Additionally, re-using the same instance may leverage hot-spot optimizations of the respective JavaScript engine.
 
 Note that this means that if your parser "carries" additional state, that state should also be reset.
-Simply override the Parser's [reset](https://chevrotain.io/documentation/9_1_0/classes/cstparser.html#reset) method
+Simply override the Parser's [reset](https://chevrotain.io/documentation/9_1_0/classes/CstParser.html#reset) method
 to accomplish that.
 
 ## Ensuring Lexer Optimizations
@@ -44,7 +44,7 @@ To apply this optimization the first possible charCodes for **every** TokenType
 Sometimes a TokenType's first charCodes cannot be automatically identified.
 In that case the lexer will **silently** revert to using the unoptimized algorithms.
 
-If the TokenType's first charCodes cannot be automatically identified, you can set the [`start_chars_hint`](https://chevrotain.io/documentation/9_1_0/interfaces/itokenconfig.html#start_chars_hint) property when calling `createToken()`. If you define a custom [pattern](https://chevrotain.io/documentation/9_1_0/interfaces/itokenconfig.html#pattern) for your token, then you should set `start_chars_hint` manually for optimal performance.
+If the TokenType's first charCodes cannot be automatically identified, you can set the [`start_chars_hint`](https://chevrotain.io/documentation/9_1_0/interfaces/ITokenConfig.html#start_chars_hint) property when calling `createToken()`. If you define a custom [pattern](https://chevrotain.io/documentation/9_1_0/interfaces/ITokenConfig.html#pattern) for your token, then you should set `start_chars_hint` manually for optimal performance.
 
 It it possible to configure the Lexer **throw** an error
 in case the optimizations cannot be enabled by turning on the
@@ -168,7 +168,7 @@ It is important to note that:
 These are only required if you are trying to squeeze every tiny bit of performance out of your parser.
 
 1.  **Reduce the amount of Token position tracking** the lexer performs.
-    See The [ILexerConfig.positionTracking](https://chevrotain.io/documentation/9_1_0/interfaces/ilexerconfig.html) property.
+    See The [ILexerConfig.positionTracking](https://chevrotain.io/documentation/9_1_0/interfaces/ILexerConfig.html) property.
 
 2.  **Avoid creating parsing rules which only parse a single Terminal.**
 

packages/website/docs/guide/resolving_grammar_errors.md

@@ -68,7 +68,7 @@ due to performance and grammar complexity reasons.
 From a performance perspective this is particularly problematic as some analysis
 done on the grammar (during initialization) may become **exponentially** more complex as the maxLookahead grows.
 
-We could also specify the [MAX_LOOKAHEAD](https://chevrotain.io/documentation/9_1_0/interfaces/ormethodopts.html#ignore_ambiguities)
+We could also specify the [MAX_LOOKAHEAD](https://chevrotain.io/documentation/9_1_0/interfaces/OrMethodOpts.html#IGNORE_AMBIGUITIES)
 config on the **specific** DSL method invocation where the problem occurs, This is still not the optimal solution in this case.
 
 **_The recommended solution in this case would be to refactor the grammar to require a smaller lookahead_**.
@@ -201,5 +201,5 @@ For example:
   ])
   ```
 
-[maxlookahead]: https://chevrotain.io/documentation/9_1_0/interfaces/iparserconfig.html#maxlookahead
-[ignore_ambiguities]: https://chevrotain.io/documentation/9_1_0/interfaces/ormethodopts.html#ignore_ambiguities
+[maxlookahead]: https://chevrotain.io/documentation/9_1_0/interfaces/IParserConfig.html#maxLookAhead
+[ignore_ambiguities]: https://chevrotain.io/documentation/9_1_0/interfaces/OrMethodOpts.html#IGNORE_AMBIGUITIES

packages/website/docs/guide/syntactic_content_assist.md

@@ -10,7 +10,7 @@ for quick starting, see:
 ## Introduction
 
 Chevrotain provides Syntactic Content assist Capabilities.
-These can be accessed via the [**computeContentAssist**](https://chevrotain.io/documentation/9_1_0/classes/cstparser.html#computecontentassist) method.
+These can be accessed via the [**computeContentAssist**](https://chevrotain.io/documentation/9_1_0/classes/CstParser.html#computeContentAssist) method.
 
 Note that this feature **only** provides syntactic suggestions (meaning next possible token types) **not** semantic suggestions.
 It could be used as a building block in a semantic suggestions provider, but it cannot do this on "its own".

packages/website/docs/tutorial/step1_lexing.md

@@ -28,7 +28,7 @@ const createToken = chevrotain.createToken
 const From = createToken({ name: "From", pattern: /FROM/ })
 ```
 
-There is nothing much to it. We simply use the [**createToken** API](https://chevrotain.io/documentation/9_1_0/modules.html#createtoken)
+There is nothing much to it. We simply use the [**createToken** API](https://chevrotain.io/documentation/9_1_0/modules.html#createToken)
 to define the tokens, and provide it with a `name` property and a `pattern` property which is a RegExp which will be used when splitting up the input string
 into separate Tokens.