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

Add lint to prevent (most) URLs #104

Open
SamWilsn opened this issue Aug 14, 2024 · 10 comments
Open

Add lint to prevent (most) URLs #104

SamWilsn opened this issue Aug 14, 2024 · 10 comments
Assignees
Labels
ready to implement Feature has reached rough consensus among editors and is ready to be implemented

Comments

@SamWilsn
Copy link
Contributor

SamWilsn commented Aug 14, 2024

Summary

Many authors attempt to bypass markdown-rel-links by putting their URL in backticks:

Check out `https://google.com`.

We should add a lint to make sure that all HTTP(S) URLs that are not hyperlinked (so in code fences, backticks, plain text, etc.) use example domains. Specifically, the following (and any subdomains thereof) would be allowed:

  • example
  • example.com
  • example.net
  • example.org
  • invalid
  • test

Examples

Disallowed

The following snippets should trigger this lint:

  • Check out `https://google.com/hello`.
    • Disallowed because:
      • the domain is not on the list above; and
      • the URL is not in a link.
  • With the following command:
    
    ```
    curl https://google.com/hello
    ```
    • Disallowed because:
      • the domain is not on the list above; and
      • the URL is not in a link.
  • Here is an unhyperlinked link http://google.com
    • Disallowed because:
      • the domain is not on the list above; and
      • the URL is not in a link.

Allowed

While the following should not trigger this lint:

  • Check out `https://example.com/hello`.
    • Allowed because the domain is on the approved list above.
  • With the following command:
    
    ```
    curl https://google.com.invalid/hello
    ```
    • Allowed because the domain is on the approved list above.
  • <https://google.com>
    • Allowed because the URL appears in a link.
  • [boop](https://google.com)
    • Allowed because the URL appears in a link.
  • [boop]
    [boop]: https://google.com
    • Allowed because the URL appears in a link.
@SamWilsn SamWilsn added the ready to implement Feature has reached rough consensus among editors and is ready to be implemented label Aug 14, 2024
@KoxyG
Copy link

KoxyG commented Sep 4, 2024

Hi @SamWilsn i want to work on this. Kindly assign me to this issue

@SamWilsn
Copy link
Contributor Author

SamWilsn commented Sep 4, 2024

Go for it!

@KoxyG
Copy link

KoxyG commented Sep 4, 2024

i should add this lint functionality in the "lints/markdown" folder right? @SamWilsn

@SamWilsn
Copy link
Contributor Author

SamWilsn commented Sep 4, 2024

Yep! And if you wouldn't mind adding a row to the readme, and an HTML file in the docs folder, I'd appreciate it!

@KoxyG
Copy link

KoxyG commented Sep 4, 2024

okay so, basically what i am meant to do are:

  1. Create a lint functionality in the "eipw-lint/src/lints/markdown" folder.
  2. Update the 'markdown-rel-links' in the READme.
  3. Update the "docs/markdown-rel-links/index.html" in the docs.

Is this well stated?.

@SamWilsn
Copy link
Contributor Author

SamWilsn commented Sep 4, 2024

This should be a separate lint from markdown-rel-links. Maybe it could be markdown-must-hyperlink or something? The name isn't too important.

So the full scope of work is:

  • Add the new lint in eipw-lint/src/lints/markdown/something.rs
  • Add it to DefaultLints
  • Add a default configuration in eipw-lint/src/lib.rs
  • Write some tests. I usually do a few normal tests (example.) You can also write an end-to-end test (example) but that's probably overkill for this lint.
  • Add a row to README.md.
  • Add a new directory and HTML file in docs/. Note that the directory name has to match the lint name.

Hopefully I haven't missed anything!

@KoxyG
Copy link

KoxyG commented Sep 4, 2024

i understand it better now. Thanks

KoxyG added a commit to KoxyG/eipw that referenced this issue Sep 4, 2024
@KoxyG
Copy link

KoxyG commented Sep 5, 2024

Hi @SamWilsn i made a pull request here #106

@SamWilsn
Copy link
Contributor Author

SamWilsn commented Sep 5, 2024

I've added a bit more detail to the initial issue. Hopefully that makes it more clear!

@KoxyG
Copy link

KoxyG commented Sep 9, 2024

Hi @SamWilsn kindly help review. I made some changes.

#106

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready to implement Feature has reached rough consensus among editors and is ready to be implemented
Projects
None yet
Development

No branches or pull requests

2 participants