This fixes broken links in the eslint output by removing the trailing full stop.
It also makes the formatting of (the output of) the various rules consistent.
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
> I don't think this is a bug, nor a feature, nor is it really documentation.
> It's just a small nuisance that I bumped into and felt compelled to fix.
> I went with documentation as that seems the closest match
## What does this pull request do?
The elslint output of `eslint-plugin-next` contains useful links to the documentation about the various rules.
Unfortunately, on most (but not all) rules, those links are immediately followed by a full stop (`.`).
The terminal (or any parser) has no way of knowing that the full stop is not part of the URL.
So it includes it and clicking the link leads to a 404 on the nextjs.org website.
![eslint](https://user-images.githubusercontent.com/1708494/147452577-43ad4ce7-df75-4d48-ab78-70b9b8212b7e.png)
This PR fixes that by removing the full stop.
## But a final full stop is better grammar
I considered alternatives (such as [a zero-width space character](https://en.wikipedia.org/wiki/Zero-width_space#Prohibited_in_URLs)) in case the final full stop was part of the style guide or something.
However, as I went through the eslint rules, I notices that the messages for various rules were formatted inconsistently.
Some with final full stop, some without.
As such, I made the all consistent with this structure:
> [message]. See: [url]
I feel this is a better solution than using the zero-width space as these sort of invisible characters
in code can be a red flag that something fishy is going on.
I submit this pull request in the hope it will be useful, and a positive contribution to a project I have a great deal of appreciation for.
That being said, I fully understand if people would consider this a non-issue.
When an `a` tag is used to link to an internal page, but the `target="_blank"` attribute is present, ESLint should not report it as an error and should not enforce using `next/link`.
Fixes#28547
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
People have been reporting on https://github.com/vercel/next.js/pull/30973 that the `no-server-import-in-page` eslint rule is reporting false positives for `_middleware` files inside sub-page folders.
Unlike `_document`, we can have multiple `_middleware` files.
Fixes#32121
The rule [`no-html-link-for-pages`](https://nextjs.org/docs/messages/no-html-link-for-pages) will incorrectly flag an `<a>`-tag intended to download a local asset. This PR adds an exception to the rule for any anchor element with a `download` attribute.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>