Skip to content

Maintenance: convert the scripts in .github/scripts to ESM #5639

Description

@svozza

Summary

The scripts under .github/scripts are CommonJS, pinned by a local package.json with "type": "commonjs", while every package in the repo and the root package.json are ESM. list_workspaces.js (#5638) is written as ESM and cannot run until the directory is converted. The remaining three JavaScript scripts should be converted at the same time so the directory has one module system:

  • release_patch_package_json.js, run as node …/release_patch_package_json.js . from each package's prepack script
  • post_release.js, loaded with require() inside an actions/github-script step in post-release.yml
  • report_e2e_sweep.js, loaded with require() in two actions/github-script steps in sweep-stale-e2e-stacks.yml

Why is this needed?

Two module systems in one small directory means two sets of idioms (require/module.exports/__dirname versus import/export/import.meta) and a per-directory package.json whose only job is to override the root. Converting removes that override, and #5638 depends on it.

Which area does this relate to?

Automation

Solution

  1. Flip .github/scripts/package.json to "type": "module". File names stay .js, so the fifteen prepack entries pointing at the release patch script are untouched.
  2. release_patch_package_json.js: replace the two require lines with import; nothing else changes.
  3. post_release.js and report_e2e_sweep.js: replace module.exports with export default and named exports. actions/github-script evaluates its snippet as CommonJS, so the three call sites must switch from require('./.github/scripts/…') to await import() with an absolute or file:// path built from github.workspace.
  4. Verify by triggering the stale-stack sweep workflow manually before the next release, since post-release.yml only runs after a release and a bad import path is only observable in a workflow run.

Acknowledgment

Future readers

Please react with 👍 and your use case to help us understand customer demand.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

internalPRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.)

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions