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.
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.
Make the `no-unwanted-polyfillio` rule respond to the `next/script` component as well as the `script` tag.
## 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`
- [x] ~Integration~Unit 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`
This PR re-includes ESLint with some notable changes, namely a guided setup similar to how TypeScript is instantiated in a Next.js application.
To add ESLint to a project, developers will have to create an `.eslintrc` file in the root of their project or add an empty `eslintConfig` object to their `package.json` file.
```js
touch .eslintrc
```
Then running `next build` will show instructions to install the required packages needed:
<img width="862" alt="Screen Shot 2021-04-19 at 7 38 27 PM" src="https://user-images.githubusercontent.com/12476932/115316182-dfd51b00-a146-11eb-830c-90bad20ed151.png">
Once installed and `next build` is run again, `.eslintrc` will be automatically configured to include the default config:
```json
{
"extends": "next"
}
```
In addition to this change:
- The feature is now under the experimental flag and requires opt-in. After testing and feedback, it will be switched to the top-level namespace and turned on by default.
- A new ESLint shareable configuration package is included that can be extended in any application with `{ extends: 'next' }`
- This default config extends recommended rule sets from [`eslint-plugin-react`](https://www.npmjs.com/package/eslint-plugin-react), [`eslint-plugin-react-hooks`](https://www.npmjs.com/package/eslint-plugin-react-hooks), and [`eslint-plugin-next`](https://www.npmjs.com/package/@next/eslint-plugin-next)
- All rules in [`eslint-plugin-next`](https://www.npmjs.com/package/@next/eslint-plugin-next) have been modified to include actionable links that show more information to help resolve each issue
- Introduces a lint rule which points towards the unwanted polyfill.io features.
- Aim here is to make the user aware that which of the requested features are actually required vs which are already covered under `next-polyfills`
Next step: If the remaining required polyfills amounts to a only a few KBs then its better to include them in 1P javascript and remove the third party render blocking script tag.
