chore(docker): simplify dotnet and add nodejs dockerfile

[iplaylf2]

Summary by CodeRabbit

• New Features

  • Added Node.js development environment with configurable version management

• Chores

  • Improved .NET development environment build efficiency

Quick Notes

• Title: Set the PR title to @coderabbitai to have the bot generate one for you.

• Review: The bot reviews PRs by default. To opt out, add the no bot reviewer label.

[coderabbitai]

Walkthrough

The pull request modifies the dotnet Dockerfile to replace a multi-step builder approach with direct curl-based installation, and introduces a new Node.js Dockerfile that uses FNM for Node version management with conditional SDK version installation support.

Changes

Cohort / File(s)	Summary
Dotnet installer refactoring images/dotnet/Dockerfile	Removes builder stage and working directory setup; replaces script-based installation with direct curl piping to bash, preserving --channel parameter
Node.js image creation images/nodejs/Dockerfile	New Dockerfile using mcr.microsoft.com/devcontainers/base:latest; adds FNM installer via remote script with conditional SDK version installation based on SDK_VERSION ARG

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• The dotnet change is a straightforward simplification with direct curl replacement
• Node.js Dockerfile is new but follows a linear, declarative structure without complex conditional logic
• Both files contain standard Docker directives without intricate dependencies or error-handling patterns requiring deep scrutiny

Possibly related PRs

• chore(ci): add GitHub Actions and Docker configuration #1 — Directly conflicts with dotnet Dockerfile changes; that PR adds a builder stage with BuildKit mount while this PR removes the builder and uses curl installation instead.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description only contains placeholder template text with no actual description of changes, objectives, or rationale for the pull request.	Replace the template placeholder with a meaningful description explaining the changes made to the Dockerfiles, why these changes were necessary, and any testing or validation performed.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/image/nodejs

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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.}

[coderabbitai]

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

images/dotnet/Dockerfile (1)

1-1: Pin the base image to a specific version instead of using :latest.

Using latest on the base image can cause unpredictable build failures when the image is updated, impacting reproducibility and CI/CD reliability. The current pinned version for this image is 2 (e.g., mcr.microsoft.com/devcontainers/base:2).

Update to:

-FROM mcr.microsoft.com/devcontainers/base:latest
+FROM mcr.microsoft.com/devcontainers/base:2

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 54c355f and 888655f.

📒 Files selected for processing (2)

• images/dotnet/Dockerfile (1 hunks)
• images/nodejs/Dockerfile (1 hunks)

🧰 Additional context used

🪛 Checkov (3.2.334)

images/nodejs/Dockerfile

[low] 1-1: Ensure the base image uses a non latest version tag

(CKV_DOCKER_7)

---

[low] 1-8: Ensure that HEALTHCHECK instructions have been added to container images

(CKV_DOCKER_2)

images/dotnet/Dockerfile

[low] 1-9: Ensure that HEALTHCHECK instructions have been added to container images

(CKV_DOCKER_2)

🪛 Hadolint (2.14.0)

images/nodejs/Dockerfile

[warning] 1-1: Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag

(DL3007)

---

[warning] 6-6: Set the SHELL option -o pipefail before RUN with a pipe in it. If you are using /bin/sh in an alpine image or if your shell is symlinked to busybox then consider explicitly setting your SHELL to /bin/ash, or disable this check

(DL4006)

images/dotnet/Dockerfile

[warning] 9-9: Set the SHELL option -o pipefail before RUN with a pipe in it. If you are using /bin/sh in an alpine image or if your shell is symlinked to busybox then consider explicitly setting your SHELL to /bin/ash, or disable this check

(DL4006)

🔇 Additional comments (1)

images/nodejs/Dockerfile (1)

4-8: Verify fnm install behavior and SDK_VERSION handling.

The conditional logic on line 8 is sound: fnm install only runs when SDK_VERSION is explicitly provided. However, verify that:

1. FNM is properly initialized in the shell environment after installation (line 6) so subsequent RUN commands can use the fnm command.
2. The shell context is preserved between RUN instructions when fnm install executes.

Consider adding explicit shell initialization if needed, or document the expected container usage pattern.