Add rootDir setting to eslint-plugin-next (#27918)
## Introduction
This PR enables setting a `rootDir` for a Next.js project, and follows the same pattern used by [`@typescript-eslint/parser`](https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/parser#parseroptionsproject).
## Details
Previously, users had to pass paths to the rule itself.
```js
module.exports = {
rules: {
"@next/next/no-html-link-for-pages": [
"error",
// This could be a string, or array of strings.
"/packages/my-app/pages",
],
},
};
```
With this PR, this has been simplified (the previous implementation still works as expected).
```js
module.exports = {
settings: {
next: {
rootDir: "/packages/my-app",
},
},
rules: {
"@next/next/no-html-link-for-pages": "error",
},
};
```
Further, this rule allows the use of globs, again aligning with `@typescript-eslint/parser`.
```js
module.exports = {
settings: {
next: {
// Globs
rootDir: "/packages/*",
rootDir: "/packages/{app-a,app-b}",
// Arrays
rootDir: ["/app-a", "/app-b"],
// Arrays with globs
rootDir: ["/main-app", "/other-apps/*"],
},
};
```
This enables users to either provide per-workspace configuration with overrides, or to use globs for situations like monorepos where the apps share a domain (micro-frontends).
This doesn't solve, but improves https://github.com/vercel/next.js/issues/26330.
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] 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
- [x] Make sure the linting passes
2021-08-11 12:37:55 +02:00
|
|
|
const NodeAttributes = require('../utils/node-attributes.js')
|
2021-05-10 20:35:11 +02:00
|
|
|
|
|
|
|
module.exports = {
|
|
|
|
meta: {
|
|
|
|
docs: {
|
|
|
|
description:
|
|
|
|
'Ensure passHref is assigned if child of Link component is a custom component',
|
|
|
|
category: 'HTML',
|
|
|
|
recommended: true,
|
2021-10-16 08:16:41 +02:00
|
|
|
url: 'https://nextjs.org/docs/messages/link-passhref',
|
2021-05-10 20:35:11 +02:00
|
|
|
},
|
|
|
|
fixable: null,
|
|
|
|
},
|
|
|
|
|
|
|
|
create: function (context) {
|
|
|
|
let linkImport = null
|
|
|
|
|
|
|
|
return {
|
|
|
|
ImportDeclaration(node) {
|
|
|
|
if (node.source.value === 'next/link') {
|
|
|
|
linkImport = node.specifiers[0].local.name
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
|
|
|
JSXOpeningElement(node) {
|
|
|
|
if (node.name.name !== 'Link' || node.name.name !== linkImport) {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
const attributes = new NodeAttributes(node)
|
|
|
|
const children = node.parent.children
|
|
|
|
|
|
|
|
if (
|
|
|
|
!attributes.hasAny() ||
|
|
|
|
!attributes.has('href') ||
|
|
|
|
!children.some((attr) => attr.type === 'JSXElement')
|
|
|
|
) {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
const hasPassHref =
|
|
|
|
attributes.has('passHref') &&
|
|
|
|
(typeof attributes.value('passHref') === 'undefined' ||
|
|
|
|
attributes.value('passHref') === true)
|
|
|
|
|
|
|
|
const hasAnchorChild = children.some(
|
|
|
|
(attr) =>
|
2021-06-18 15:17:53 +02:00
|
|
|
attr.type === 'JSXElement' && attr.openingElement.name.name === 'a'
|
2021-05-10 20:35:11 +02:00
|
|
|
)
|
|
|
|
|
|
|
|
if (!hasAnchorChild && !hasPassHref) {
|
|
|
|
context.report({
|
|
|
|
node,
|
|
|
|
message: `passHref ${
|
|
|
|
attributes.value('passHref') !== true
|
|
|
|
? 'must be set to true'
|
|
|
|
: 'is missing'
|
fix(eslint-plugin-next): Broken links in eslint output (#32837)
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.
2021-12-28 03:18:39 +01:00
|
|
|
}. See: https://nextjs.org/docs/messages/link-passhref`,
|
2021-05-10 20:35:11 +02:00
|
|
|
})
|
|
|
|
}
|
|
|
|
},
|
|
|
|
}
|
|
|
|
},
|
|
|
|
}
|