first-interaction: Import error when using the action in a workflow

Hey! Our team has been enjoying this action for a long time now, but today we started getting this error:

internal/modules/cjs/loader.js:1216
      throw new ERR_REQUIRE_ESM(filename, parentPath, packageJsonPath);
      ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /node_modules/@octokit/graphql/index.js
require() of ES modules is not supported.
require() of /node_modules/@octokit/graphql/index.js from /node_modules/@actions/github/lib/github.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /node_modules/@octokit/graphql/package.json.

    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1216:13)
    at Module.load (internal/modules/cjs/loader.js:1049:32)
    at Function.Module._load (internal/modules/cjs/loader.js:937:14)
    at Module.require (internal/modules/cjs/loader.js:1089:19)
    at require (internal/modules/cjs/helpers.js:73:18)
    at Object.<anonymous> (/node_modules/@actions/github/lib/github.js:14:19)
    at Module._compile (internal/modules/cjs/loader.js:1200:[30](https://github.com/creditornot/ops-tools/actions/runs/3150609247/jobs/5123593663#step:3:31))
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1220:10)
    at Module.load (internal/modules/cjs/loader.js:1049:[32](https://github.com/creditornot/ops-tools/actions/runs/3150609247/jobs/5123593663#step:3:33))
    at Function.Module._load (internal/modules/cjs/loader.js:9[37](https://github.com/creditornot/ops-tools/actions/runs/3150609247/jobs/5123593663#step:3:38):14) {
  code: 'ERR_REQUIRE_ESM'
}

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 41
  • Comments: 15 (2 by maintainers)

Commits related to this issue

Most upvoted comments

If the action is non-blocking for your repo, you can use jobs.<job_id>.steps[*].continue-on-error:

name: Greetings

on: [pull_request_target]

jobs:
    greeting:
        runs-on: ubuntu-latest
        permissions:
            issues: write
            pull-requests: write
        if: ${{ github.actor != 'dependabot[bot]' }}
        steps:
            - uses: actions/first-interaction@v1
              continue-on-error: true
              with:
                  repo-token: ${{ secrets.GITHUB_TOKEN }}
                  pr-message: 'Something'

v1.1.1 of this action has been released with the change from #103. Reference to v1 has been updated to v1.1.1 as well.

Hi everyone! Thanks for reporting this, we’re aware of the issue

Just made a PR to fix this. But I don’t know who is supposed to review it.

This action should be using release tags so that we can lock to a working version. The continue-on-error workaround is a good short-term solution.

Happens for me as well.

name: Greetings

on: [pull_request_target]

jobs:
    greeting:
        runs-on: ubuntu-latest
        permissions:
            issues: write
            pull-requests: write
        if: ${{ github.actor != 'dependabot[bot]' }}
        steps:
            - uses: actions/first-interaction@v1
              with:
                  repo-token: ${{ secrets.GITHUB_TOKEN }}
                  pr-message: 'Gratulerer med din første PR!'

Same here with default configuration.

Just noticed the problem for one of my repos as well.

Have the same problem with the default workflow configuration