chore(ci): test on node@22 and node@24

[rhamzeh]

Description

Test on recent node versions, 22 (LTS) and 24 (current, upcoming LTS), change base build to node@24.

See: https://nodejs.org/en/about/previous-releases#release-schedule

What problem is being solved?

How is it being solved?

What changes are made to solve it?

References

Review Checklist

• I have clicked on "allow edits by maintainers".
• I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
• The correct base branch is being used, if not main
• I have added tests to validate that the change in functionality is working as expected

Summary by CodeRabbit

• Chores
  • Continuous integration now runs against a broader Node.js range (16.x–24.x), improving coverage and compatibility of builds and tests.
  • Node.js version configuration is centralized across jobs to ensure consistent environments during build, test, and publish steps.
  • No user-facing changes; these updates enhance the reliability of release pipelines without altering application behavior.

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

Updated the GitHub Actions workflow to introduce a root-level NODE_VERSION env var, expand the Node.js version matrix to include 22.x and 24.x, and standardize setup-node steps to use the env-driven version across build, test, and publish jobs.

Changes

Cohort / File(s)	Summary of changes
CI workflow updates .github/workflows/main.yaml	Added env NODE_VERSION: '24.x'; expanded matrix to [16.x, 18.x, 20.x, 22.x, 24.x]; replaced hard-coded node-version with ${{ env.NODE_VERSION }} in setup steps across jobs.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~7 minutes

Suggested reviewers

• sergiught

✨ Finishing Touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore/ci-node-versions

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

• Visit our Status Page to check the current availability of CodeRabbit.
• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.16%. Comparing base (2d57837) to head (461c2b0).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #247   +/-   ##
=======================================
  Coverage   88.16%   88.16%           
=======================================
  Files          23       23           
  Lines        1217     1217           
  Branches      216      197   -19     
=======================================
  Hits         1073     1073           
  Misses         86       86           
  Partials       58       58           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2fc7d56 and d20f869.

📒 Files selected for processing (1)

• .github/workflows/main.yaml (3 hunks)

🔇 Additional comments (2)

.github/workflows/main.yaml (2)

93-93: Publishing on 24.x: make the source of the version explicit after removing the global env.

If you remove the root-level env, this reference will break. Either hardcode the desired publish version or set a job-level env for publish.

Apply one of the following:

Option A — hardcode 24.x here:

-          node-version: ${{ env.NODE_VERSION }}
+          node-version: '24.x'

Option B — set job-level env and keep this line:

# inside `publish:` job
env:
  NODE_VERSION: '24.x'

Note: Consider publishing with the active LTS (22.x) unless you require Node 24 features. Verify your release pipeline (npm, node-gyp, optional native deps) is compatible with Node 24 before switching.

---

21-21: CI Matrix & Engine Check for Node 16

We’ve verified the engines.node fields in all package.json files:

• repo root (package.json): ≥16.15.0
• example1/package.json: ≥16.13.0
• opentelemetry/package.json: ≥16.13.0

No .nvmrc files were found and no other workflows pin Node 16. Since your packages still support Node 16, it’s safe to keep 16.x in the CI matrix. If you’d rather drop Node 16 to reduce EOL-related flakiness, please:

• Remove 16.x from the matrix in .github/workflows/main.yaml
• Update all engines.node entries in your package.json files to >=18.x

[rhamzeh]

Audit failure is fixed by #248

[sergiught]

[question] Shouldn't this be ${{ matrix.node-version }} ? And I believe we shouldn't have any env with a node version at the top otherwise it will override all the builds. See comment from rabbitai https://github.com/openfga/js-sdk/pull/247/files#r2269791797