chore(docker): align Node version with engines requirement

[Harsh16gupta]

What

Align Docker base image with the Node version required by the project and fix Docker test failures caused by turbo prune --docker excluding required runtime files.

Fixes #1815
Fixes #1813

---

Why

1. Node version mismatch

The project requires:

• node >= 24.11
• npm >= 11.5.1

However, the Dockerfile previously used Node 18, causing npm ci to fail with an EBADENGINE error during Docker builds.

2. Docker + turbo prune issue

When running tests inside Docker, turbo prune --docker excludes files that are not part of the dependency graph but are still required at runtime, including:

• the shared root jest.config.base.js (required for Jest tests)
• packages/templates (required by build-templates.js during generator build)

This caused Docker-based test and build failures, while local (non-Docker) runs succeeded.

---

Result

• Docker builds now use Node 24.11, matching the project’s engines requirements.
• Docker test execution no longer fails due to missing shared Jest configuration.
• Generator build succeeds in Docker by explicitly restoring runtime template assets excluded by turbo prune.
• Docker builds and tests complete successfully without manual workarounds.

---

Summary by CodeRabbit

• Chores
  • Updated the Node.js runtime from 18 to 24.11 to align with project engine requirements.
  • Included testing configuration and template assets into the final build image to ensure necessary runtime resources are present.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0ae734d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

📝 Walkthrough

Walkthrough

Updated the Dockerfile: bumped NODE_VERSION from 18 to 24.11 and added copy steps to include jest.config.base.js and packages/templates from the installer stage into the final image.

Changes

Cohort / File(s)	Change Summary
Dockerfile Dockerfile	Bumped NODE_VERSION from 18 to 24.11 (base image now node:${NODE_VERSION}-alpine); added COPY --from=installer ... jest.config.base.js into final stage; added COPY --from=installer ... packages/templates into final stage.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title uses the Conventional Commits format with 'chore' prefix and clearly summarizes the main change: aligning Node version with the engines requirement in the Dockerfile.
Linked Issues check	✅ Passed	The PR successfully addresses all coding requirements from linked issues #1815 and #1813: bumping NODE_VERSION to 24.11 satisfies the engines requirement, and restoring jest.config.base.js and packages/templates resolves Docker test failures.
Out of Scope Changes check	✅ Passed	All changes in the Dockerfile are directly related to the linked issues: updating Node version and restoring excluded files via turbo prune. No unrelated modifications are present.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b326872 and 0ae734d.

📒 Files selected for processing (1)

• Dockerfile

🚧 Files skipped from review as they are similar to previous changes (1)

• Dockerfile

---

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

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[asyncapi-bot]

What reviewer looks at during PR review

The following are ideal points maintainers look for during review. Reviewing these points yourself beforehand can help streamline the review process and reduce time to merge.

1. PR Title: Use a concise title that follows our Conventional Commits guidelines and clearly summarizes the change using imperative mood (it means spoken or written as if giving a command or instruction, like "add new helper for listing operations")

   Note - In Generator, prepend feat: or fix: in PR title only when PATCH/MINOR release must be triggered.

2. PR Description: Clearly explain the issue being solved, summarize the changes made, and mention the related issue.

   Note - In Generator, we use Maintainers Work board to track progress. Ensure the PR Description includes Resolves #<issue-number> or Fixes #<issue-number> this will automatically close the linked issue when the PR is merged and helps automate the maintainers workflow.

3. Documentation: Update the relevant Generator documentation to accurately reflect the changes introduced in the PR, ensuring users and contributors have up-to-date guidance.

4. Comments and JSDoc: Write clear and consistent JSDoc comments for functions, including parameter types, return values, and error conditions, so others can easily understand and use the code.

5. DRY Code: Ensure the code follows the Don't Repeat Yourself principle. Look out for duplicate logic that can be reused.

6. Test Coverage: Ensure the new code is well-tested with meaningful test cases that pass consistently and cover all relevant edge cases.

7. Commit History: Contributors should avoid force-pushing as much as possible. It makes it harder to track incremental changes and review the latest updates.

8. Template Design Principles Alignment: While reviewing template-related changes in the packages/ directory, ensure they align with the Assumptions and Principles. If any principle feels outdated or no longer applicable, start a discussion these principles are meant to evolve with the project.

9. Reduce Scope When Needed: If an issue or PR feels too large or complex, consider splitting it and creating follow-up issues. Smaller, focused PRs are easier to review and merge.

10. Bot Comments: As reviewers, check that contributors have appropriately addressed comments or suggestions made by automated bots. If there are bot comments the reviewer disagrees with, react to them or mark them as resolved, so the review history remains clear and accurate.

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6be5453 and aed0cdf.

📒 Files selected for processing (1)

• Dockerfile

[Adi-204]

@Harsh16gupta, please first familiarize yourself with the AsyncAPI Generator repository guidelines by carefully reading the CONTRIBUTING.md file: https://github.com/asyncapi/generator/blob/master/CONTRIBUTING.md
Also, do not open a pull request without first validating the issue with one of the maintainers.
Additionally, the screenshot included in the PR description should be part of the corresponding issue. Please add a screenshot showing the result after applying your changes.

[Harsh16gupta]

@Adi-204 Thanks for pointing this out, and apologies for missing the process earlier.
I’ll go through the Generator CONTRIBUTING.md carefully and make sure to validate issues with a maintainer before opening PRs going forward.
I have created an issue
#1815

I have also moved the screenshot from the PR description to the corresponding issue and add an updated screenshot showing the result after applying the change.

[Adi-204]

lgtm!

[Adi-204]

@Harsh16gupta This issue is now resolved—thanks for working on it.
Since this PR is quite small, I would recommend also addressing #1813
in the same PR if you’re planning to work on it?

[Adi-204]

Also read Note in point 1 in this comment and change title of the PR remove fix with chore.

[Harsh16gupta]

@Adi-204 I will work on it as directed

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Harsh16gupta]

@Adi-204
While validating the Docker changes, Docker builds and test execution run successfully through the generator and template tests.

The remaining failure observed during docker compose up occurs when template integration tests are executed together via Turbo. In this mode, Jest reports an obsolete snapshot in template-kafka-integration-test.

Running the same test workspace in isolation (npm test inside the package) passes with all snapshots intact, and the issue is not introduced by this PR.

I’ve intentionally not updated snapshots here to keep the scope limited to Docker and turbo prune --docker–related fixes.

[Adi-204]

@Harsh16gupta We cannot merge the PR until docker compose up runs successfully. Please take your time to make the required changes and ensure everything passes.