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

Allow selection between warning, error and ignoring regarding the validity of links #77

Closed
4 tasks done
santi100a opened this issue Aug 22, 2023 · 9 comments
Closed
4 tasks done
Labels
🙅 no/wontfix This is not (enough of) an issue for this project 👎 phase/no Post cannot or will not be acted on

Comments

@santi100a
Copy link

Initial checklist

Problem

It's kinda jarring and odd to use --frail to catch warnings as errors and exit with 1. Also, other Remark warnings could cause errors if they are raised at lint time.

Solution

We should be able to specify the severity to be reported as "error", "warn" or "ignore".
Example:

{
    "plugins": {
           "validate-links": {
                     "settings": {
                          "severity": "error" // also warn or ignore
                    }
           }
    }
}

Alternatives

Another way would be to directly modify Remark itself, but I think this is much better.

@github-actions github-actions bot added 👋 phase/new Post is being triaged automatically 🤞 phase/open Post is being triaged manually and removed 👋 phase/new Post is being triaged automatically labels Aug 22, 2023
@wooorm
Copy link
Member

wooorm commented Aug 23, 2023

Continuing this conversation on from https://github.com/orgs/remarkjs/discussions/1217#discussioncomment-6796453:

What do you mean, “jarring”?

Why do you think broken URLs are errors?

What else are you using? Are you only using remark-validate-links?

It'd be nice if Remark could be adjusted like ESLint to bypass the severity of certain rules.

ESLint is just a linter.
remark isn’t just a linter. remark does many things: it can lint, but it also transforms.
On errors, it stops: because errors are fatal errors.
On warnings, it continues.
If this package would see broken URLs as errors, like you suggest, and there would be one of those broken URLs, nothing after this package will run. It stops. Because it’s an error. What nice about that?


From here:

Also, other Remark warnings could cause errors if they are raised at lint time.

Can you expand on this scenario? What do you mean?

Another way would be to directly modify Remark itself, but I think this is much better.

You mean the package remark? How would you change it?


Errors vs warnings in unified mean something. I don’t think you want the actual behavior that that difference results in.

@santi100a
Copy link
Author

Also, other Remark warnings could cause errors if they are raised at lint time.

Can you expand on this scenario? What do you mean?

What if I used another Remark plugin and it raises a warning? If I use --frail, Remark will fail even if I only want it to fail if validate-links warns, not other plugins.

@wooorm
Copy link
Member

wooorm commented Aug 28, 2023

If you use plugins that raise regular messages, plugins run.
If one plugin uses a fatal message (an “error”), other plugins don’t run. Files are not written.

--frail is unrelated to this process. It exits with 1 if there was a regular or fatal message, instead of the normal 1 only for fatal messages.

@santi100a
Copy link
Author

So the solution is to run Remark for link validation with --frail and run further linting without this flag.

@wooorm
Copy link
Member

wooorm commented Aug 28, 2023

You never explained what your problem is, you proposed a solution.

I think the solution for your problem is to use --frail. And then you’re done?

@wooorm
Copy link
Member

wooorm commented Aug 28, 2023

What you mention just now as a solution would be a solution to what you are proposing here though. To turn warnings for links into errors. Then you’d need to run twice.
If you don‘t turn warnings into errors, you don‘t need to run twice.

@santi100a
Copy link
Author

I guess yes. I thought Remark errors were like linter errors.

@wooorm
Copy link
Member

wooorm commented Sep 14, 2023

Closing as I don’t yet think there is a good reason to add such code, --frail seems like a better solution.

@wooorm wooorm closed this as not planned Won't fix, can't repro, duplicate, stale Sep 14, 2023
@wooorm wooorm added the 🙅 no/wontfix This is not (enough of) an issue for this project label Sep 14, 2023
@github-actions

This comment has been minimized.

@github-actions github-actions bot added 👎 phase/no Post cannot or will not be acted on and removed 🤞 phase/open Post is being triaged manually labels Sep 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🙅 no/wontfix This is not (enough of) an issue for this project 👎 phase/no Post cannot or will not be acted on
Development

No branches or pull requests

2 participants