awesome-lint
awesome-lint copied to clipboard
Add rule for linting header image if one exists
Based on discussion in https://github.com/sindresorhus/awesome/pull/1314.
- [ ] If a header image exists (aside from awesome-list badge), ensure it is high-DPI or SVG.
There is a $60.00 open bounty on this issue. Add more on Issuehunt.
- Checkout the Issuehunt explorer to discover more funded issues.
- Need some help from other developers? Add your repositories on Issuehunt to raise funds.
If a header image exists (aside from awesome-list badge), ensure it is high-DPI or SVG.
How do you think we should check if an image is high-quality (in case the image isn't an SVG)?
Since a digital image has no DPI, I think we could look at the ratio between an image's size and its display size (e.g. if the size of an image is 1500x1000
and it's displayed at a size of 1200x800
, then the ratio between the areas is (1500 * 1000) / (1200 * 800) = 1.5625
, which should look pretty good).
We should also ensure the header image is displayed at its original aspect ratio.
The ratio should be at least 2x.
Based on the PR requirements, we should probably also ensure that the header image links to the project website or any relevant website.
We should also lint the project description (basically just ensuring that there's a succinct description at the top of the readme (right after the header image)), either in the same rule or in a different one (if this seems too much for a single rule).
@transitive-bullshit what do you think about https://github.com/sindresorhus/awesome-lint/issues/37#issuecomment-419862735 and this?
@itaisteinherz Your thought process sounds very reasonable.
Two thoughts:
- I would recommend that we resolve #39 before adding any new functionality to
awesome-lint
. My guess is that there'll be quite a bit of feedback and work that results from that integration as PR authors start linting their lists and providing feedback. I'd rather prioritize getting linting adopted first before adding anything new which might raise the possibility of false positives. - This one is going to be a little tricky to handle since there are multiple different ways markdown allows you to include images, and in the most common case, we'll be linting inline html which shouldn't be particularly hard but isn't trivial either.
I'd rather prioritize getting linting adopted first before adding anything new which might raise the possibility of false positives.
I completely agree 👍🏻
@issuehunt has funded $60.00 to this issue.
- Submit pull request via IssueHunt to receive this reward.
- Want to contribute? Chip in to this issue via IssueHunt.
- Checkout the IssueHunt Issue Explorer to see more funded issues.
- Need help from developers? Add your repository on IssueHunt to raise funds.