Regression in @5.0.21: `rules:` input cannot find user checker file (`Cannot find module ...`)

[Yaminyam]

Summary

Starting with @graphql-inspector/action@5.0.21 (release-1781692943029, 2026-06-17), the rules: input can no longer load a user-defined checker file from the checked-out workspace. Every run dies before doing anything useful with:

Cannot find module '/home/runner/work/<repo>/<repo>/gql-inspector-checker.js'

The same workflow pinned to release-1717403590269 (the last kamilkisiela/graphql-inspector tag, action@4.x) works fine with the ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true Node 20 opt-in.

Reproduction

Minimal workflow (the one we run on every PR in lablup/backend.ai):

graphql-inspector:
  runs-on: ubuntu-latest
  permissions:
    contents: read
    pull-requests: write
    checks: write
  steps:
    - uses: actions/checkout@v6
    - uses: graphql-hive/graphql-inspector@release-1781692943029
      with:
        schema: '${{ github.base_ref }}:docs/manager/graphql-reference/schema.graphql'
        rules: |
          gql-inspector-checker.js

gql-inspector-checker.js is at the repository root (CommonJS, module.exports = (props) => ...). It exists in main, in the PR head, and git ls-tree confirms the blob is present. The actions/checkout@v6 step completes successfully, but the action step fails as above.

Two failed mitigation attempts:

1. Anchor the path to the workspace explicitly:

   rules: |
     ${{ github.workspace }}/gql-inspector-checker.js

   → same error (the resolved absolute path appears in the error, but the action still cannot find it).

2. Disable the experimental merge so workspace stays defined:

   experimental_merge: false

   → same error.

Failing runs on a public branch: lablup/backend.ai#12291 (commits f2c0ce6, 61f5766).

What I think changed

@graphql-inspector/action@5.0.12 (release-1762976032309, 2025-11) bumped @graphql-inspector/commands to 6.0.0 via #2893, whose changelog says “Paths also needed changed to consistently and uniquely map to the node being changed.” That diff was about schema change path fields, not file-system paths — but it looks like the same release also altered (regressed) how resolveRule / ensureAbsolute locate the rules file.

Public release notes for 5.0.12 → 5.0.21 only document the Node 24 runtime fix (#2957) and dependency bumps; no mention of an intentional rules: semantics change.

Why this matters

External usage of rules: is rare (a code search of .github/workflows/*.yml across public repos turns up only built-in dangerous-changes-style usage — none invoking a user-defined .js rule). That means upstream tests don’t exercise this surface, but it’s the only way to teach the action about repo-specific change criteria (e.g. our Deprecated since XX.YY.Z version notation, see our gql-inspector-checker.js).

Workaround we’re shipping

Until this is fixed, we’re pinning to:

env:
  ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: "true"
steps:
  - uses: actions/checkout@v6
  - uses: graphql-hive/graphql-inspector@release-1717403590269
    with:
      schema: '${{ github.base_ref }}:docs/manager/graphql-reference/schema.graphql'
      rules: |
        gql-inspector-checker.js

This keeps working today but will break once GitHub retires ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION.

Ask

• Is rules: with a user-defined .js rule still a supported entry point in 5.x?
• If yes, could you confirm the expected resolution rule (relative to repo root / workspace? ${{ github.workspace }} should work?), and what 5.0.12+ changed in the resolver?
• If no longer supported, what is the recommended replacement for repo-specific rules?

[Yaminyam]

Update — bisected to 5.0.9 and located the root cause

I ran a release-by-release bisection on lablup/backend.ai's actual workflow (and gql-inspector-checker.js), opting back into Node 20 via ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true so each pin would actually execute:

@graphql-inspector/action	release tag	Result
5.0.7	release-1731490071726	✅ pass
5.0.8	release-1733751254476	✅ pass
5.0.9	release-1762508344828	❌ first failing
5.0.11	release-1762782918138	❌ fail
5.0.21	release-1781692943029	❌ fail

So the regression landed exactly in 5.0.9.

Root cause: bundler swap → ESM bundle → webpack-stubbed dynamic require

The 5.0.8 → 5.0.9 jump swaps the bundler used to produce action/index.js:

-    "@zeit/ncc": "0.22.3"
+    "@vercel/ncc": "0.38.3"

packages/action/package.json already had "type": "module" in 5.0.8, but the old @zeit/ncc@0.22.3 ignored it and emitted a CommonJS bundle. @vercel/ncc@0.38.3 honors it and emits an ESM bundle:

• action/index.js in 5.0.8 starts with module.exports=function(e,t){"use strict";... (CJS)
• action/index.js in 5.0.9 starts with import{createRequire as __WEBPACK_EXTERNAL_createRequire}from"module";... (ESM)

In the ESM bundle, the bare require(filepath) inside resolveRule:

// packages/action/src/utils.ts at release-1781692943029
export function resolveRule(name: string): Rule | undefined {
  const filepath = ensureAbsolute(name);
  if (existsSync(filepath)) {
    return require(filepath);   // ← rewritten by ncc/webpack
  }
  return DiffRule[name as keyof typeof DiffRule];
}

…is rewritten by webpack into a call into module 2410, which in the 5.0.9 bundle is webpackEmptyContext:

2410: e => {
  function webpackEmptyContext(e) {
    var t = new Error("Cannot find module '" + e + "'");
    t.code = "MODULE_NOT_FOUND";
    throw t;
  }
  ...
}

So every call to resolveRule(...) that gets past existsSync lands on a stub that unconditionally throws Cannot find module '<filepath>', regardless of whether the file actually exists on disk. That's why both gql-inspector-checker.js (relative) and ${{ github.workspace }}/gql-inspector-checker.js (absolute) produced the same Cannot find module failure on every released 5.0.9+ tag.

Good news — master already has the fix

I noticed c0ecb19a on master (the v4.0.0 release commit) replaces the bare require with an explicit createRequire(import.meta.url):

export function resolveRule(name: string): Rule | undefined {
  const filepath = ensureAbsolute(name);
  if (existsSync(filepath)) {
    // ncc rewrites bare require to its bundler require, which can't load files
    // outside the bundle. createRequire gives us a real runtime require.
    return (
      process
        // @ts-expect-error getBuiltinModule exists starting node v20.16.0
        .getBuiltinModule('module')
        .createRequire(import.meta.url)(filepath)
    );
  }
  return DiffRule[name as keyof typeof DiffRule];
}

That bypasses ncc/webpack's require rewriting and gives a real runtime require, which is exactly what's needed for the rules input to resolve user files on the runner.

Ask

Could a new release-… tag for @graphql-inspector/action be cut from the current master so this fix actually ships? Right now consumers (us, and presumably anyone else using rules:) still have to pin to release-1717403590269 + ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true because every published release-… tag still has the broken return require(filepath).

Thanks!

[ramundomario]

Same issue using release-1781692943029 tag in GHA, instead v4.0.0 works fine