[Feature] Optionally validate the link anchor or ignore using line number as anchor

[zinizhu]

Description

GitHub markdown supports using line length as the anchor, for example:

[file](index.md#L7)

I don't want the linter to throw error on this.

Describe the solution you'd like

I don't know if there is a way to optionally turn on the anchor validation for a specific line, it seems a bit complex to implement.

Instead maybe just hardcode in the plugin to ignore that?

Describe alternatives you've considered

[theoludwig]

Hey! @zinizhu

Thanks for opening this issue.
I think that's a valid use case, if effectively GitHub supports line number in # fragment.
Could you please verify that MD051 supports this use case, if having a link that refers directly to a line number in its own file (e.g: [file](#L7)). If the built-in rule doesn't support this use case, it would also be a feature to add there.

I don't know if there is a way to optionally turn on the anchor validation for a specific line, it seems a bit complex to implement.

Instead maybe just hardcode in the plugin to ignore that?

I think, we can do better than simply ignoring, and it can still stays simple. Should we validate that the line exists? In your example ([file](index.md#L7)), we should check that index.md should have at least 8 lines. If yes, then good, the custom rule should effectively not throw an error, but if index.md has for example 5 lines, it will "throw" an error saying that line 7 doesn't exist.
What do you think? 😄

Would you mind opening a PR to implement this feature?
If not, will try to implement it whenever I have time. 👍

[zinizhu]

Thanks for the quick response! I just verified that MD051 does not support this use case. It throws an error if I use line number as the anchor.

I think what you proposed can work well! Worth to note that it is possible to have a header in the same form of the line number, e.g. a header ## L7

[electriquo]

@theoludwig

I think, we can do better than simply ignoring, and it can still stays simple. Should we validate that the line exists?

Why won't to start with something that will mitigate the issue and improve over time?

[github-actions]

🎉 This issue has been resolved in version 2.3.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[theoludwig]

@theoludwig

I think, we can do better than simply ignoring, and it can still stays simple. Should we validate that the line exists?

Why won't to start with something that will mitigate the issue and improve over time?

@electriquo I agree, havent't said the contrary. However issues are there to discuss any potential ideas to improve the library. Linters are there to catch human mistakes, as much as a machine can, of course sometimes the linter is wrong, and is detecting a mistake, which is in fact is not.

Only ignoring line number fragments (e.g: #L7), or still have one more check to see if it's valid with the number of lines in a file, is not so much "harder" to do in the implementation (only 1 more if and test case), and it brings values by still catching possible mistakes (e.g: referring to line 7 #L7 in a empty file), so it makes sense to do it at the same time.

---

Anyway, this use case is now supported in the latest version (v2.3.0), please let me know if it works for you. And please, feel free to open any new issues, if you have new feature requests or bug you've encountered, thanks! 😄

(I will try whenever I have time, to open a PR to markdownlint to also support this use case there, for the MD051 rule.)

[electriquo]

Thank you @theoludwig

[zinizhu]

Thank you for supporting this in such a short span! @theoludwig