[GH-ISSUE #1365] Suggestion: Add CI to automate heavy PR load #11071

New Issue

GiteaMirror · 2026-04-21T14:09:20-05:00

GiteaMirror commented

2026-04-21 14:09:20 -05:00

Originally created by @transitive-bullshit on GitHub (Jul 29, 2018).
Original GitHub issue: https://github.com/sindresorhus/awesome/issues/1365

This would ideally combine awesome-lint with a linter for the pull requests themselves and the main awesome readme.

Related to #1363 and the goal of maintaining Sindre's sanity 💯

Here's my proposed game plan:

create a linter based off of awesome-lint that lints this repo's readme.md to verify formatting and extract all the sub-lists
this linter validates every awesome list linked to via awesome-lint
maintainers will only consider PRs once they pass this CI step

There will be some existing awesome lists that don't pass awesome-lint, so we could whitelist these for now and incrementally fix them until the whitelist can be removed.

This would also put more onus on the awesome-lint project which appears to have been inactive for some time.

Possible future extensions:

Include awesome-lint in the default awesome list template such that it would be enforced via CI for sub-awesome lists going forwards.

@sindresorhus I'd be happy to spearhead this, since I really believe these lists help countless developers out there every day, and the current gameplan of manual reviewing (even with the help of fellow list-makers) seems sub-optimal.

Originally created by @transitive-bullshit on GitHub (Jul 29, 2018). Original GitHub issue: https://github.com/sindresorhus/awesome/issues/1365 This would ideally combine [awesome-lint](https://github.com/sindresorhus/awesome-lint) with a linter for the pull requests themselves and the main `awesome` readme. Related to #1363 and the goal of maintaining Sindre's sanity 💯 Here's my proposed game plan: - create a linter based off of `awesome-lint` that lints this repo's `readme.md` to verify formatting and extract all the sub-lists - this linter validates every awesome list linked to via `awesome-lint` - maintainers will only consider PRs once they pass this CI step There will be some existing awesome lists that don't pass `awesome-lint`, so we could whitelist these for now and incrementally fix them until the whitelist can be removed. This would also put more onus on the `awesome-lint` project which appears to have been inactive for some time. Possible future extensions: - Include `awesome-lint` in the default `awesome` list template such that it would be enforced via CI for sub-awesome lists going forwards. @sindresorhus I'd be happy to spearhead this, since I really believe these lists help countless developers out there every day, and the current gameplan of manual reviewing (even with the help of fellow list-makers) seems sub-optimal.

GiteaMirror commented

2026-04-21 14:09:21 -05:00

@sindresorhus commented on GitHub (Jul 29, 2018):

I honestly think this will just create more work for us with false-positives. It's really hard to correctly lint Markdown and many of the things I comment on cannot be automatically linted.

I guess we could experiment with awesome-lint in some Awesome lists first, so any issues would only disrupt those lists an not the main Awesome list.

In short, awesome-lint will need a lot of work to be production-ready and nobody has been willing to do it. Are you?

@sindresorhus commented on GitHub (Jul 29, 2018): I honestly think this will just create more work for us with false-positives. It's really hard to correctly lint Markdown and many of the things I comment on cannot be automatically linted. I guess we could experiment with `awesome-lint` in some Awesome lists first, so any issues would only disrupt those lists an not the main Awesome list. In short, `awesome-lint` will need a lot of work to be production-ready and nobody has been willing to do it. Are you?

GiteaMirror commented

2026-04-21 14:09:22 -05:00

@sellisd commented on GitHub (Jul 29, 2018):

How about a complementary approach: encourage the automated generation of awesome lists.

To generate an awesome list that conforms to the requirements not much are needed:

A table with the list entries that could have the following format:

Category	Name	Link	Description
Platforms	Node.js	https://github.com/sindresorhus/awesome-nodejs#readme	JavaScript runtime built on Chrome's V8 JavaScript engine.
Frontend Development	...	...	...
...	...	...	...

A string with the title of the list
A header in markdown format
A footer in markdown format
An enum for license choice
A free text for code of conduct or other necessary files

A short script in ones favorite language could do the trick.

@sellisd commented on GitHub (Jul 29, 2018): How about a complementary approach: encourage the automated generation of awesome lists. To generate an awesome list that conforms to the requirements not much are needed: 1. A table with the list entries that could have the following format: |Category | Name | Link | Description| |-----------|---------|-----|------------| | Platforms |Node.js | https://github.com/sindresorhus/awesome-nodejs#readme|JavaScript runtime built on Chrome's V8 JavaScript engine.| Frontend Development|...|...|...| |...|...|...|...| 2. A string with the title of the list 3. A header in markdown format 4. A footer in markdown format 5. An enum for license choice 6. A free text for code of conduct or other necessary files A short script in ones favorite language could do the trick.

GiteaMirror commented

2026-04-21 14:09:22 -05:00

@sindresorhus commented on GitHub (Jul 29, 2018):

@sellisd Awesome lists should be hand-made.

We already link to a generator to make it easier to get started: https://github.com/dar5hak/generator-awesome-list

@sindresorhus commented on GitHub (Jul 29, 2018): @sellisd Awesome lists should be hand-made. We already link to a generator to make it easier to get started: https://github.com/dar5hak/generator-awesome-list

GiteaMirror commented

2026-04-21 14:09:23 -05:00

@transitive-bullshit commented on GitHub (Jul 29, 2018):

In short, awesome-lint will need a lot of work to be production-ready and nobody has been willing to do it. Are you?

Yes :) See my first PR for awesome-lint. I've actually worked quite a bit with unist and the remark ecosystem, and I'm excited to work on this.

There will still be a need for manual review of submissions, but I really think that just having an obvious RED LIGHT when someone creates a PR request because of failing some basic linting check will make your life easier as a maintainer.

Our goal with the linter shouldn't be to catch all false-positives. It should be to make it very clear when submitting that the author hasn't adhered to basic guidelines. As long as the linter can't produce false-negatives (e.g., linter says your readme is invalid, but it's really okay), then I think this will be an overall win for cutting down the time it takes to deal with submissions.

@transitive-bullshit commented on GitHub (Jul 29, 2018): > In short, awesome-lint will need a lot of work to be production-ready and nobody has been willing to do it. Are you? Yes :) See my first [PR](https://github.com/sindresorhus/awesome-lint/pull/22) for awesome-lint. I've actually worked quite a bit with unist and the remark ecosystem, and I'm excited to work on this. There will still be a need for manual review of submissions, but I really think that just having an obvious RED LIGHT when someone creates a PR request because of failing some basic linting check will make your life easier as a maintainer. Our goal with the linter shouldn't be to catch all false-positives. It should be to make it very clear when submitting that the author hasn't adhered to basic guidelines. As long as the linter can't produce false-negatives (e.g., linter says your readme is invalid, but it's really okay), then I think this will be an overall win for cutting down the time it takes to deal with submissions.

GiteaMirror commented

2026-04-21 14:09:24 -05:00

@sindresorhus commented on GitHub (Jul 29, 2018):

@transitive-bullshit Good to hear. Let's make this happen then :)

@sindresorhus commented on GitHub (Jul 29, 2018): @transitive-bullshit Good to hear. Let's make this happen then :)

GiteaMirror commented

2026-04-21 14:09:25 -05:00

@sisirkoppaka commented on GitHub (Dec 24, 2019):

@sindresorhus @transitive-bullshit Added a PR ( #1675 ) for linting awesome itself with awesome-lint as a GitHub Action which should shine more light early in the PR review process on linting success check.

Do share your thoughts.

@sisirkoppaka commented on GitHub (Dec 24, 2019): @sindresorhus @transitive-bullshit Added a PR ( #1675 ) for linting awesome itself with `awesome-lint` as a GitHub Action which should shine more light early in the PR review process on linting success check. Do share your thoughts.

GiteaMirror commented

2026-04-21 14:09:26 -05:00

@brandonzane11 commented on GitHub (Apr 22, 2025):

How can I fix?

@brandonzane11 commented on GitHub (Apr 22, 2025): How can I fix?

GiteaMirror commented

2026-04-21 14:09:26 -05:00

@Angel-Mathew007 commented on GitHub (Sep 4, 2025):

Hi @sindresorhus and everyone,
It would be great to revisit this and improve the linting setup for Awesome itself. Enhancing awesome-lint and integrating a robust CI workflow could help maintain quality and consistency across lists.
If anyone wants to collaborate or needs help with this, I’m happy to contribute!

@Angel-Mathew007 commented on GitHub (Sep 4, 2025): Hi @sindresorhus and everyone, It would be great to revisit this and improve the linting setup for Awesome itself. Enhancing awesome-lint and integrating a robust CI workflow could help maintain quality and consistency across lists. If anyone wants to collaborate or needs help with this, I’m happy to contribute!

GiteaMirror commented

2026-04-21 14:09:27 -05:00

@its-abhaykumar commented on GitHub (Jan 19, 2026):

Thanks for this excellent suggestion!

I’d like to help implement CI for this repo. I propose using a workflow that:

Runs awesome-lint on all PRs
Checks formatting and list validity
Recognizes/whitelists known exceptions
Fails the workflow only on real errors

Before building it, I’d like feedback on stack choice (GitHub Actions vs. others) and whitelist policy.

@its-abhaykumar commented on GitHub (Jan 19, 2026): Thanks for this excellent suggestion! I’d like to help implement CI for this repo. I propose using a workflow that: 1. Runs `awesome-lint` on all PRs 2. Checks formatting and list validity 3. Recognizes/whitelists known exceptions 4. Fails the workflow only on real errors Before building it, I’d like feedback on stack choice (GitHub Actions vs. others) and whitelist policy.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/awesome-sindresorhus#11071