Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Rule: rules regarding actual content #288

Closed
1 task
ghost opened this issue Oct 7, 2024 · 2 comments
Closed
1 task

New Rule: rules regarding actual content #288

ghost opened this issue Oct 7, 2024 · 2 comments
Labels

Comments

@ghost
Copy link

ghost commented Oct 7, 2024

Rule details

I am missing out a whole category of rules that are also not for formatting, but also are not focused only on general document structure as you have provided gently until now.

What type of rule is this?

Warns about a potential problem

Example code

Inspired by https://github.com/DavidAnson/markdownlint I would like to see rules such as:
strong-style - Sets a consistent pattern for Strong style (** or __)
ul-style - Sets a consistent pattern for Unordered list style (* or -)
link-image-style - Sets a consistent pattern for Link and image style (inline or by reference)

Also not bad to see:
no-reversed-links - Reversed link syntax
no-trailing-punctuation - Trailing punctuation in heading
single-title/single-h1 - Multiple top-level headings in the same document
table-column-count - Table column count should equal the header count
first-line-heading/first-line-h1 - Requires First line in a file to be a top-level heading
heading-increment - Requires Heading levels to be only increment by one level at a time
no-alt-text - Images should have alternate text (alt text)
no-bare-urls - requires URLs to contain <>.
no-duplicate-heading - forbids headings with the same title/anchor.
no-empty-links - disallows to write empty URLs.
And many more that do not conflict with Prettier.

Participation

  • I am willing to submit a pull request to implement this rule.

Additional comments

Please consider that I am going to delete this account for reasons outside of my reach. So please keep this issue opened or absorb it under your work, because it is very appropriate for you to find valid inspiration in markdownlint, that is worth to take a look to make @eslint/markdown good enough or even better.

Also could you consider elaborating more the rules that you plan to develop for @eslint/markdown (roadmap), to let users help you to develop them and also >>to let users decide if are ever going to replace remark-lint or markdownlint in favor of @eslint/markdown, or not.

PS: https://github.com/theoludwig/markdownlint-rule-relative-links is the only plugin that I find relevant, that should have been written as a markdownlint core rule. Please consider it when planning your new rules.

@ghost ghost added the feature label Oct 7, 2024
@eslintbot eslintbot added this to Triage Oct 7, 2024
@github-project-automation github-project-automation bot moved this to Needs Triage in Triage Oct 7, 2024
@nzakas
Copy link
Member

nzakas commented Oct 16, 2024

It seems like you haven't reviewed the available rules in this plugin, as many of the ones you mentioned already exist. We are purposely not implementing rules that can be handled by Prettier.

I'm not sure what the "delete account" thing means, but if you want to open an issue for a specific rule that doesn't already exist, please do so.

@nzakas nzakas closed this as not planned Won't fix, can't repro, duplicate, stale Oct 16, 2024
@github-project-automation github-project-automation bot moved this from Needs Triage to Complete in Triage Oct 16, 2024
@ghost
Copy link

ghost commented Oct 25, 2024

@nzakas Oh pardon... I was going to suggest 1 or 2 new rules. In the end I decided to mention more suggestions... I mixed the lists of rules by mistake in notepad and then I ended up suggesting some available rules... I hope you have enjoyed half of the suggestions I have offered, which seem to be valid......

When I used to use markdownlint, I have disabled the stylistic rules in markdownlint, in favor of Prettier handling them. That is to say that: among the rules I have suggested in my previous comment, I understand they are non-stylistic rules. Because they are rules that Prettier does not enforce anything at all.
...in the end you may know better than me what is a style rule or not...... anyway, this is another feedback... in any case, I am sure that someone may get into contact with the people related to @stylistic/eslint-plugin, or other plugin authors to see if some dev has the wish to create a new package named @stylistic/markdown-plugin (for ESLint), inspired on stylistic rules as seen in markdownlint maybe... Differently from other languages, Markdown is so related to content that I believe the "style" category of rules deserves to be satisfied in this way or another...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

No branches or pull requests

1 participant