rsnext/packages/eslint-plugin-next/lib/rules/link-passhref.js
Joost De Cock 34dcede690
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 02:18:39 +00:00

64 lines
1.7 KiB
JavaScript

const NodeAttributes = require('../utils/node-attributes.js')
module.exports = {
meta: {
docs: {
description:
'Ensure passHref is assigned if child of Link component is a custom component',
category: 'HTML',
recommended: true,
url: 'https://nextjs.org/docs/messages/link-passhref',
},
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) =>
attr.type === 'JSXElement' && attr.openingElement.name.name === 'a'
)
if (!hasAnchorChild && !hasPassHref) {
context.report({
node,
message: `passHref ${
attributes.value('passHref') !== true
? 'must be set to true'
: 'is missing'
}. See: https://nextjs.org/docs/messages/link-passhref`,
})
}
},
}
},
}