Permalink
Browse files

Docs: Fix broken links (#9488)

  • Loading branch information...
gpiress authored and Aladdin-ADD committed Oct 20, 2017
1 parent 51bdb2f commit 87db8aeb495d898d5404a5943babfc31e9f2ee6c
@@ -14,27 +14,27 @@ In order to work with ESLint as a developer, it's recommended that:
If that sounds like you, then continue reading to get started.
## Section 1: Get the [Source Code](source-code)
## Section 1: Get the [Source Code](source-code.md)
Before you can get started, you'll need to get a copy of the ESLint source code. This section explains how to do that and a little about the source code structure.
## Section 2: Set up a [Development Environment](development-environment)
## Section 2: Set up a [Development Environment](development-environment.md)
Developing for ESLint is a bit different than running it on the command line. This section shows you how to set up a development environment and get you ready to write code.
## Section 3: Run the [Unit Tests](unit-tests)
## Section 3: Run the [Unit Tests](unit-tests.md)
There are a lot of unit tests included with ESLint to make sure that we're keeping on top of code quality. This section explains how to run the unit tests.
## Section 4: [Working with Rules](working-with-rules)
## Section 4: [Working with Rules](working-with-rules.md)
You're finally ready to start working with rules. You may want to fix an existing rule or create a new one. This section explains how to do all of that.
## Section 5: [Working with Plugins](working-with-plugins)
## Section 5: [Working with Plugins](working-with-plugins.md)
You've developed library-specific rules for ESLint and you want to share it with the community. You can publish an ESLint plugin on npm.
## Section 6: [Node.js API](nodejs-api)
## Section 6: [Node.js API](nodejs-api.md)
If you're interested in writing a tool that uses ESLint, then you can use the Node.js API to get programmatic access to functionality.
@@ -16,22 +16,22 @@ In order to submit code or documentation to an ESLint project, you will need to
Think you found a problem? We'd love to hear about it. This section explains how to submit a bug, the type of information we need to properly verify it, and the overall process.
## Proposing a [New Rule](new-rules)
## Proposing a [New Rule](new-rules.md)
We get a lot of proposals for new rules in ESLint. This section explains how we determine which rules are accepted and what information you should provide to help us evaluate your proposal.
## Proposing a [Rule Change](rule-changes)
## Proposing a [Rule Change](rule-changes.md)
Want to make a change to an existing rule? This section explains the process and how we evaluate such proposals.
## Requesting a [Change](changes)
## Requesting a [Change](changes.md)
If you'd like to request a change other than a bug fix or new rule, this section explains that process.
## [Working on Issues](working-on-issues)
## [Working on Issues](working-on-issues.md)
Have some extra time and want to contribute? This section talks about the process of working on issues.
## Submitting a [Pull Request](pull-requests)
## Submitting a [Pull Request](pull-requests.md)
We're always looking for contributions from the community. This section explains the requirements for pull requests and the process of contributing code.
@@ -19,7 +19,7 @@ Even though these are the formal criteria for inclusion, each rule is evaluated
## Proposing a Rule
If you want to propose a new rule, [create a pull request](/docs/developer-guide/contributing/pull-requests) or new issue and paste the questions from the [rule proposal template](https://github.com/eslint/eslint/blob/master/templates/rule-proposal.md) into the description.
If you want to propose a new rule, [create a pull request](/docs/developer-guide/contributing/pull-requests.md) or new issue and paste the questions from the [rule proposal template](https://github.com/eslint/eslint/blob/master/templates/rule-proposal.md) into the description.
We need all of this information in order to determine whether or not the rule is a good core rule candidate.
@@ -39,4 +39,4 @@ The ESLint team doesn't implement new rules that are suggested by users because
## Alternative: Creating Your Own Rules
Remember that ESLint is completely pluggable, which means you can create your own rules and distribute them using plugins. We did this on purpose because we don't want to be the gatekeepers for all possible rules. Even if we don't accept a rule into the core, that doesn't mean you can't have the exact rule that you want. See the [working with rules](../working-with-rules) and [working with plugins](../working-with-plugins) documentation for more information.
Remember that ESLint is completely pluggable, which means you can create your own rules and distribute them using plugins. We did this on purpose because we don't want to be the gatekeepers for all possible rules. Even if we don't accept a rule into the core, that doesn't mean you can't have the exact rule that you want. See the [working with rules](../working-with-rules.md) and [working with plugins](../working-with-plugins.md) documentation for more information.
@@ -7,8 +7,8 @@ If you want to contribute to an ESLint repo, please use a GitHub pull request. T
If you'd like to work on a pull request and you've never submitted code before, follow these steps:
1. Sign our [Contributor License Agreement](https://cla.js.foundation/eslint/eslint).
1. Set up a [development environment](../development-environment).
1. If you want to implement a breaking change or a change to the core, ensure there's an issue that describes what you're doing and the issue has been accepted. You can create a new issue or just indicate you're [working on an existing issue](working-on-issues). Bug fixes, documentation changes, and other pull requests do not require an issue.
1. Set up a [development environment](../development-environment.md).
1. If you want to implement a breaking change or a change to the core, ensure there's an issue that describes what you're doing and the issue has been accepted. You can create a new issue or just indicate you're [working on an existing issue](working-on-issues.md). Bug fixes, documentation changes, and other pull requests do not require an issue.
After that, you're ready to start working on code.
@@ -40,7 +40,7 @@ You should do all of your development for the issue in this branch.
### Step 2: Make your changes<a name="step2"></a>
Make the changes to the code and tests, following the [code conventions](../code-conventions) as you go. Once you have finished, commit the changes to your branch:
Make the changes to the code and tests, following the [code conventions](../code-conventions.md) as you go. Once you have finished, commit the changes to your branch:
```
$ git add -A
@@ -68,7 +68,7 @@ The `Tag` is one of the following:
* `Upgrade` - for a dependency upgrade.
* `Chore` - for refactoring, adding tests, etc. (anything that isn't user-facing).
Use the [labels of the issue you are working on](working-on-issues#issue-labels) to determine the best tag.
Use the [labels of the issue you are working on](working-on-issues.md#issue-labels) to determine the best tag.
The message summary should be a one-sentence description of the change, and it must be 72 characters in length or shorter. If the pull request addresses an issue, then the issue number should be mentioned at the end. If the commit doesn't completely fix the issue, then use `(refs #1234)` instead of `(fixes #1234)`.
@@ -168,7 +168,7 @@ When updating the code, it's usually better to add additional commits to your br
### Rebasing
If your code is out-of-date, we might ask you to rebase. That means we want you to apply your changes on top of the latest upstream code. Make sure you have set up a [development environment](../development-environment) and then you can rebase using these commands:
If your code is out-of-date, we might ask you to rebase. That means we want you to apply your changes on top of the latest upstream code. Make sure you have set up a [development environment](../development-environment.md) and then you can rebase using these commands:
```
$ git fetch upstream
@@ -1,6 +1,6 @@
# Reporting Bugs
If you think you've found a bug in ESLint, please [create a new issue](https://github.com/eslint/eslint/issues/new) or a [pull request](/docs/developer-guide/contributing/pull-requests) on GitHub. Be sure to copy the questions from the [bug report template](https://github.com/eslint/eslint/blob/master/templates/bug-report.md).
If you think you've found a bug in ESLint, please [create a new issue](https://github.com/eslint/eslint/issues/new) or a [pull request](/docs/developer-guide/contributing/pull-requests.md) on GitHub. Be sure to copy the questions from the [bug report template](https://github.com/eslint/eslint/blob/master/templates/bug-report.md).
Please include as much detail as possible to help us properly address your issue. If we need to triage issues and constantly ask people for more detail, that's time taken away from actually fixing issues. Help us be as efficient as possible by including a lot of detail in your issues.
@@ -4,15 +4,15 @@ Occasionally, a core ESLint rule needs to be changed. This is not necessarily a
## Proposing a Rule Change
To propose a change to an existing rule, [create a new issue](https://github.com/eslint/eslint/issues/new) or a [pull request](/docs/developer-guide/contributing/pull-requests) on GitHub. Be sure to copy the questions from the [rule change proposal template](https://github.com/eslint/eslint/blob/master/templates/rule-change-proposal.md).
To propose a change to an existing rule, [create a new issue](https://github.com/eslint/eslint/issues/new) or a [pull request](/docs/developer-guide/contributing/pull-requests.md) on GitHub. Be sure to copy the questions from the [rule change proposal template](https://github.com/eslint/eslint/blob/master/templates/rule-change-proposal.md).
We need all of this information in order to determine whether or not the change is a good candidate for inclusion.
## Accepting a Rule Change
In order for a rule change to be accepted into ESLint, it must:
1. Adhere to the [Core Rule Guidelines](new-rules#core-rule-guidelines)
1. Adhere to the [Core Rule Guidelines](new-rules.md#core-rule-guidelines)
1. Have an ESLint team member champion the change
1. Be important enough that rule is deemed incomplete without this change
@@ -67,8 +67,8 @@ The most important method on `Linter` is `verify()`, which initiates linting of
* **Note**: If you want to lint text and have your configuration be read and processed, use CLIEngine's [`executeOnFiles`](#executeonfiles) or [`executeOnText`](#executeontext) instead.
* `options` - (optional) Additional options for this run.
* `filename` - (optional) the filename to associate with the source code.
* `preprocess` - (optional) A function that accepts a string containing source text, and returns an array of strings containing blocks of code to lint. Also see: [Processors in Plugins](/docs/developer-guide/working-with-plugins#processors-in-plugins)
* `postprocess` - (optional) A function that accepts an array of problem lists (one list of problems for each block of code from `preprocess`), and returns a one-dimensional array of problems containing problems for the original, unprocessed text. Also see: [Processors in Plugins](/docs/developer-guide/working-with-plugins#processors-in-plugins)
* `preprocess` - (optional) A function that accepts a string containing source text, and returns an array of strings containing blocks of code to lint. Also see: [Processors in Plugins](/docs/developer-guide/working-with-plugins.md#processors-in-plugins)
* `postprocess` - (optional) A function that accepts an array of problem lists (one list of problems for each block of code from `preprocess`), and returns a one-dimensional array of problems containing problems for the original, unprocessed text. Also see: [Processors in Plugins](/docs/developer-guide/working-with-plugins.md#processors-in-plugins)
* `allowInlineConfig` - (optional) set to `false` to disable inline comments from changing eslint rules.
* `reportUnusedDisableDirectives` - (optional) when set to `true`, adds reported errors for unused `eslint-disable` directives when no problems would be reported in the disabled area anyway.
@@ -90,7 +90,7 @@ If multiple selectors have equal specificity, their listeners will be called in
### Restricting syntax with selectors
With the [no-restricted-syntax](/docs/rules/no-restricted-syntax) rule, you can restrict the usage of particular syntax in your code. For example, you can use the following configuration to disallow using `if` statements that do not have block statements as their body:
With the [no-restricted-syntax](/docs/rules/no-restricted-syntax.md) rule, you can restrict the usage of particular syntax in your code. For example, you can use the following configuration to disallow using `if` statements that do not have block statements as their body:
```json
{
@@ -132,7 +132,7 @@ configs: {
}
```
**Note:** Please note that configuration will not automatically attach your rules and you have to specify your plugin name and any rules you want to enable that are part of the plugin. Any plugin rules must be prefixed with the short or long plugin name. See [Configuring Plugins](../user-guide/configuring#configuring-plugins)
**Note:** Please note that configuration will not automatically attach your rules and you have to specify your plugin name and any rules you want to enable that are part of the plugin. Any plugin rules must be prefixed with the short or long plugin name. See [Configuring Plugins](../user-guide/configuring.md#configuring-plugins)
### Peer Dependency
@@ -149,7 +149,7 @@ The plugin support was introduced in ESLint version `0.8.0`. Ensure the `peerDep
### Testing
ESLint provides the [`RuleTester`](/docs/developer-guide/nodejs-api#ruletester) utility to make it easy to test the rules of your plugin.
ESLint provides the [`RuleTester`](/docs/developer-guide/nodejs-api.md#ruletester) utility to make it easy to test the rules of your plugin.
## Share Plugins
@@ -32,7 +32,7 @@ module.exports.schema = []; // no options
## Rule Basics
`schema` (array) specifies the [options](#options-schemas) so ESLint can prevent invalid [rule configurations](../user-guide/configuring#configuring-rules)
`schema` (array) specifies the [options](#options-schemas) so ESLint can prevent invalid [rule configurations](../user-guide/configuring.md#configuring-rules)
`create` (function) returns an object with methods that ESLint calls to "visit" nodes while traversing the abstract syntax tree (AST as defined by [ESTree](https://github.com/estree/estree)) of JavaScript code:
@@ -42,7 +42,7 @@ module.exports.schema = []; // no options
A rule can use the current node and its surrounding tree to report or fix problems.
Here are methods for the [array-callback-return](../rules/array-callback-return) rule:
Here are methods for the [array-callback-return](../rules/array-callback-return.md) rule:
```js
function checkLastSegment (node) {
@@ -72,7 +72,7 @@ module.exports = function(context) {
The `context` object contains additional functionality that is helpful for rules to do their jobs. As the name implies, the `context` object contains information that is relevant to the context of the rule. The `context` object has the following properties:
* `parserOptions` - the parser options configured for this run (more details [here](../user-guide/configuring#specifying-parser-options)).
* `parserOptions` - the parser options configured for this run (more details [here](../user-guide/configuring.md#specifying-parser-options)).
* `id` - the rule ID.
* `options` - an array of rule options.
* `settings` - the `settings` from configuration.
@@ -476,7 +476,7 @@ valid: [
]
```
The options available and the expected syntax for `parserOptions` is the same as those used in [configuration](../user-guide/configuring#specifying-parser-options).
The options available and the expected syntax for `parserOptions` is the same as those used in [configuration](../user-guide/configuring.md#specifying-parser-options).
### Write Several Tests
@@ -571,5 +571,5 @@ The thing that makes ESLint different from other linters is the ability to defin
Runtime rules are written in the same format as all other rules. Create your rule as you would any other and then follow these steps:
1. Place all of your runtime rules in the same directory (i.e., `eslint_rules`).
2. Create a [configuration file](../user-guide/configuring) and specify your rule ID error level under the `rules` key. Your rule will not run unless it has a value of `1` or `2` in the configuration file.
3. Run the [command line interface](../user-guide/command-line-interface) using the `--rulesdir` option to specify the location of your runtime rules.
2. Create a [configuration file](../user-guide/configuring.md) and specify your rule ID error level under the `rules` key. Your rule will not run unless it has a value of `1` or `2` in the configuration file.
3. Run the [command line interface](../user-guide/command-line-interface.md) using the `--rulesdir` option to specify the location of your runtime rules.
Oops, something went wrong.

0 comments on commit 87db8ae

Please sign in to comment.