Docs: Fix leaky anchors in v4 migration page (#13635)

docs/user-guide/migrating-to-4.0.0.md

@@ -30,7 +30,7 @@ The lists below are ordered roughly by the number of users each change is expect
 
 ---
 
-## <a name="eslint-recommended-changes"/> `eslint:recommended` changes
+## <a name="eslint-recommended-changes"></a> `eslint:recommended` changes
 
 Two new rules have been added to the [`eslint:recommended`](https://eslint.org/docs/user-guide/configuring#using-eslintrecommended) config:
 
@@ -50,7 +50,7 @@ Two new rules have been added to the [`eslint:recommended`](https://eslint.org/d
 }
 ```
 
-## <a name="indent-rewrite"/> The `indent` rule is more strict
+## <a name="indent-rewrite"></a> The `indent` rule is more strict
 
 Previously, the [`indent`](/docs/rules/indent) rule was fairly lenient about checking indentation; there were many code patterns where indentation was not validated by the rule. This caused confusion for users, because they were accidentally writing code with incorrect indentation, and they expected ESLint to catch the issues.
 
@@ -69,25 +69,25 @@ To make the upgrade process easier, we've introduced the [`indent-legacy`](/docs
 }
 ```
 
-## <a name="config-validation"/> Unrecognized properties in config files now cause a fatal error
+## <a name="config-validation"></a> Unrecognized properties in config files now cause a fatal error
 
 When creating a config, users sometimes make typos or misunderstand how the config is supposed to be structured. Previously, ESLint did not validate the properties of a config file, so a typo in a config could be very tedious to debug. Starting in 4.0.0, ESLint will raise an error if a property in a config file is unrecognized or has the wrong type.
 
 **To address:** If you see a config validation error after upgrading, verify that your config doesn't contain any typos. If you are using an unrecognized property, you should be able to remove it from your config to restore the previous behavior.
 
-## <a name="eslintignore-patterns"/> .eslintignore patterns are now resolved from the location of the file
+## <a name="eslintignore-patterns"></a> .eslintignore patterns are now resolved from the location of the file
 
 Due to a bug, glob patterns in an `.eslintignore` file were previously resolved from the current working directory of the process, rather than the location of the `.eslintignore` file. Starting in 4.0, patterns in an `.eslintignore` file will be resolved from the `.eslintignore` file's location.
 
 **To address:** If you use an `.eslintignore` file and you frequently run ESLint from somewhere other than the project root, it's possible that the patterns will be matched differently. You should update the patterns in the `.eslintignore` file to ensure they are relative to the file, not to the working directory.
 
-## <a name="padded-blocks-defaults"/> The `padded-blocks` rule is more strict by default
+## <a name="padded-blocks-defaults"></a> The `padded-blocks` rule is more strict by default
 
 By default, the [`padded-blocks`](/docs/rules/padded-blocks) rule will now enforce padding in class bodies and switch statements. Previously, the rule would ignore these cases unless the user opted into enforcing them.
 
 **To address:** If this change results in more linting errors in your codebase, you should fix them or reconfigure the rule.
 
-## <a name="space-before-function-paren-defaults"/> The `space-before-function-paren` rule is more strict by default
+## <a name="space-before-function-paren-defaults"></a> The `space-before-function-paren` rule is more strict by default
 
 By default, the [`space-before-function-paren`](/docs/rules/space-before-function-paren) rule will now enforce spacing for async arrow functions. Previously, the rule would ignore these cases unless the user opted into enforcing them.
 
@@ -105,7 +105,7 @@ By default, the [`space-before-function-paren`](/docs/rules/space-before-functio
 }
 ```
 
-## <a name="no-multi-spaces-eol-comments"/> The `no-multi-spaces` rule is more strict by default
+## <a name="no-multi-spaces-eol-comments"></a> The `no-multi-spaces` rule is more strict by default
 
 By default, the [`no-multi-spaces`](/docs/rules/no-multi-spaces) rule will now disallow multiple spaces before comments at the end of a line. Previously, the rule did not check this case.
 
@@ -119,7 +119,7 @@ By default, the [`no-multi-spaces`](/docs/rules/no-multi-spaces) rule will now d
 }
 ```
 
-## <a name="scoped-plugin-resolution"/> References to scoped plugins in config files are now required to include the scope
+## <a name="scoped-plugin-resolution"></a> References to scoped plugins in config files are now required to include the scope
 
 In 3.x, there was a bug where references to scoped NPM packages as plugins in config files could omit the scope. For example, in 3.x the following config was legal:
 
@@ -153,13 +153,13 @@ To avoid this ambiguity, in 4.0 references to scoped plugins must include the sc
 
 ---
 
-## <a name="rule-tester-validation"/> `RuleTester` now validates properties of test cases
+## <a name="rule-tester-validation"></a> `RuleTester` now validates properties of test cases
 
 Starting in 4.0, the `RuleTester` utility will validate properties of test case objects, and an error will be thrown if an unknown property is encountered. This change was added because we found that it was relatively common for developers to make typos in rule tests, often invalidating the assertions that the test cases were trying to make.
 
 **To address:** If your tests for custom rules have extra properties, you should remove those properties.
 
-## <a name="comment-attachment"/> AST Nodes no longer have comment properties
+## <a name="comment-attachment"></a> AST Nodes no longer have comment properties
 
 Prior to 4.0, ESLint required parsers to implement comment attachment, a process where AST nodes would gain additional properties corresponding to their leading and trailing comments in the source file. This made it difficult for users to develop custom parsers, because they would have to replicate the confusing comment attachment semantics required by ESLint.
 
@@ -177,7 +177,7 @@ Finally, please note that the following `SourceCode` methods have been deprecate
 * `getTokenOrCommentBefore()` - replaced by `getTokenBefore()` with the `{ includeComments: true }` option
 * `getTokenOrCommentAfter()` - replaced by `getTokenAfter()` with the `{ includeComments: true }` option
 
-## <a name="event-comments"/> `LineComment` and `BlockComment` events will no longer be emitted during AST traversal
+## <a name="event-comments"></a> `LineComment` and `BlockComment` events will no longer be emitted during AST traversal
 
 Starting in 4.0, `LineComment` and `BlockComments` events will not be emitted during AST traversal. There are two reasons for this:
 
@@ -191,7 +191,7 @@ sourceCode.getAllComments().filter(comment => comment.type === "Line");
 sourceCode.getAllComments().filter(comment => comment.type === "Block");
 ```
 
-## <a name="shebangs"/> Shebangs are now returned from comment APIs
+## <a name="shebangs"></a> Shebangs are now returned from comment APIs
 
 Prior to 4.0, shebang comments in a source file would not appear in the output of `sourceCode.getAllComments()` or `sourceCode.getComments()`, but they would appear in the output of `sourceCode.getTokenOrCommentBefore` as line comments. This inconsistency led to some confusion for rule developers.
 
@@ -205,21 +205,21 @@ sourceCode.getAllComments().filter(comment => comment.type !== "Shebang");
 
 ---
 
-## <a name="global-property"/> The `global` property in the `linter.verify()` API is no longer supported
+## <a name="global-property"></a> The `global` property in the `linter.verify()` API is no longer supported
 
 Previously, the `linter.verify()` API accepted a `global` config option, which was a synonym for the documented `globals` property. The `global` option was never documented or officially supported, and did not work in config files. It has been removed in 4.0.
 
 **To address:** If you were using the `global` property, please use the `globals` property instead, which does the same thing.
 
-## <a name="report-locations"/> More report messages now have full location ranges
+## <a name="report-locations"></a> More report messages now have full location ranges
 
 Starting in 3.1.0, rules have been able to specify the *end* location of a reported problem, in addition to the start location, by explicitly specifying an end location in the `report` call. This is useful for tools like editor integrations, which can use the range to precisely display where a reported problem occurs. Starting in 4.0, if a *node* is reported rather than a location, the end location of the range will automatically be inferred from the end location of the node. As a result, many more reported problems will have end locations.
 
 This is not expected to cause breakage. However, it will likely result in larger report locations than before. For example, if a rule reports the root node of the AST, the reported problem's range will be the entire program. In some integrations, this could result in a poor user experience (e.g. if the entire program is highlighted to indicate an error).
 
 **To address:** If you have an integration that deals with the ranges of reported problems, make sure you handle large report ranges in a user-friendly way.
 
-## <a name="exposed-es2015-classes"/> Some exposed APIs are now ES2015 classes
+## <a name="exposed-es2015-classes"></a> Some exposed APIs are now ES2015 classes
 
 The `CLIEngine`, `SourceCode`, and `RuleTester` modules from ESLint's Node.js API are now ES2015 classes. This will not break any documented behavior, but it does have some observable effects (for example, the methods on `CLIEngine.prototype` are now non-enumerable).