feat: create update-readme.yml

[lumirlumir]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request?

Overview

In this PR, I created the update-readme.yml workflow.

I inlined and consolidated the logic that was originally in tools/commit-readme.sh, tools/update-readme.js, and .github/workflows/update-readme.yml in each repository.

The original implementation used the got package to fetch data, but the workflow now runs on Node.js LTS and the native fetch API is available, so the got package is no longer needed.

Support both multirepo and monorepo setups

This workflow works well for both multirepo and monorepo setups.

According to #4, 7 repositories use the update-readme script.

There are two types of the update-readme script: one updates only the root-level README.md (multirepo), and the other updates all README.md files under the packages directory as well as the root-level README.md (monorepo).

I've taken these two types of update-readme script into account.

Multirepo

• https://github.com/eslint/markdown/blob/main/tools/update-readme.js
• https://github.com/eslint/json/blob/main/tools/update-readme.js
• https://github.com/eslint/css/blob/main/tools/update-readme.js
• https://github.com/eslint/code-explorer/blob/main/tools/update-readme.js

Monorepo

• https://github.com/eslint/rewrite/blob/main/tools/update-readme.js
• https://github.com/eslint/js/blob/main/tools/update-readme.js

Exception

eslint/eslint repository is an exception, as it uses a slightly different form of the update-readme script.

• https://github.com/eslint/eslint/blob/main/tools/update-readme.js

How did you test this change?

I've tested the workflow in my personal repository ( https://github.com/lumirlumir/test-update-readme ) with my Personal Access Token and confirmed it works correctly for both multirepo and monorepo setups.

Multirepo test example

https://github.com/lumirlumir/test-update-readme/commit/c0663488a3e2b1b4a756f9cbe9961cc27e87c462

https://github.com/lumirlumir/test-update-readme/actions/runs/17358680977/job/49275514381

Monorepo test example

https://github.com/lumirlumir/test-update-readme/commit/c14102ea1063121e6d34b12ed17ad00a46ada303

https://github.com/lumirlumir/test-update-readme/actions/runs/17380613326/job/49337017695

What changes did you make? (Give an overview)

In this PR, I created the update-readme.yml workflow.

Related Issues

Ref: #4
Fixes: #6

Is there anything you'd like reviewers to focus on?

There is a prerequisite for this workflow to function as expected:

• Is WORKFLOW_PUSH_BOT_TOKEN secret set at the organization level?

[lumirlumir]

If it's okay, could this PR include only a ## Sponsors heading for now, so we can verify the update-readme workflow is working correctly in the workflows repository?

[nzakas]

• Is WORKFLOW_PUSH_BOT_TOKEN secret set at the organization level?

Yes

[nzakas]

I really don't like having this JavaScript in the YAML file. It makes it difficult to maintain and debug when something goes wrong. Can we move this into an external JavaScript file?

[lumirlumir]

I've explored some alternatives and run several tests, but getting an external JavaScript file to work in a reusable workflow requires a lot of additional setup.

---

For example, the recommended way to run external JavaScript is to create a "JavaScript Action" following the GitHub guide: https://docs.github.com/en/actions/tutorials/create-actions/create-a-javascript-action (Most of the current Actions using JavaScript in the GitHub Actions Marketplace follow this approach.)

However, this approach requires quite a bit of setup. It requires installing npm packages such as @actions/core and @actions/github, and a bundler like Webpack or Rollup. I looked for alternatives, but a reusable JavaScript Action can't be implemented without these setups.

I think this approach matches what you mentioned in #6 (comment) and would add additional overhead for very little gain.

---

Another possible approach would be to avoid consolidating tools/commit-readme.sh and tools/update-readme.js into the workflow and instead keep them as external scripts that live in each repository as they do now. However, this would require every repository to include tools/commit-readme.sh and tools/update-readme.js. (This is what I was trying to avoid when suggesting #6.)

---

Yes, I agree that inline JavaScript makes debugging and maintenance harder, but the actual implementation is only about 20 lines, so given the overhead required to get external JavaScript working, inline JavaScript seems the simplest way to achieve the goal.

If debugging is the main concern, I can have the workflow log as much debugging information as possible. I think adding more logging to the workflow would help alleviate concerns if something goes wrong.

[nzakas]

I don't understand. Can't you just create a JavaScript file in this repository and have the workflow execute it?

[lumirlumir]

Can't you just create a JavaScript file in this repository and have the workflow execute it?

Adding a JavaScript file named tools/update-readme.js (or similar) to this eslint/workflows repository and updating the YAML script as shown below will not work in other repositories.

---

This is because, for example, if we run this reusable workflow in the eslint/json repository, the workflow runs in that repository. The default becomes eslint/json, not eslint/workflows.

So, if we check out the repository using actions/checkout@v5, only the eslint/json repository is cloned into the GitHub Actions runner. Therefore, the tools/update-readme.js file in the eslint/workflows repository is not accessible, since files from eslint/workflows are not cloned into the runner.

---

If inline JavaScript is indeed a problem (I'm not sure there's a way around it), I'll try to find a simpler way to implement this workflow. If I can't find any alternatives, I'll let you know in a comment.

[nzakas]

Could we have an external JavaScript file in this repo, and in the workflow use curl to download it and then execute it?

[lumirlumir]

I've updated the workflow to use curl in e7ab9a7.

I tested it on my personal repository and found that it works as expected:

• https://github.com/lumirlumir/test-update-readme/commit/a585bcba39616ffbde5a63d1204b941c2ff84038
• https://github.com/lumirlumir/test-update-readme/actions/runs/17894460128/job/50879203725

[aladdin-add]

LGTM. leaving it open for @nzakas to re-review before merging.

[nzakas]

LGTM.