build: upgrade runtime to Node 24.19.0 and TypeScript 5.9.3

[dhairyathareja1]

Node.js 24 Upgrade

Summary

This PR upgrades the bot's runtime from Node.js 8 to Node.js 24 and modernizes the associated npm, TypeScript, Docker, launcher, and CI configuration.

It does not intentionally change the bot's commands or business logic.

Core changes

• Upgraded Node.js from 8.10.0 to 24.19.0.
• Added .nvmrc to keep local development and CI on the same Node.js version.
• Updated the supported npm version to npm 11 and added npm@11.17.0 as the package manager.
• Upgraded TypeScript from 4.9.5 to 5.9.3.
• Upgraded @types/node from Node 8 typings to Node 24 typings.
• Updated the TypeScript output target from ES2017/CommonJS to ES2024 with NodeNext module resolution.
• Refreshed package-lock.json using the new npm version.
• Added consolidated check, type-check, build, test, and Heroku post-build commands.
• Updated Unix and Windows Hubot launchers for the current installation and build process.
• Added --legacy-peer-deps where required because the currently merged Hubot dependency tree contains incompatible peer-dependency declarations.
• Updated start_bot.sh to use the Node.js version from .nvmrc.
• Added GitHub Actions coverage for installation, type-checking, regression tests, Docker image construction, and compiled-module loading.
• Replaced the separate development Dockerfile with a multi-stage production Dockerfile and updated the Docker Compose configuration accordingly.
• Updated the README with the Node.js 24 development workflow.

Docker changes

The Docker image now uses separate build and runtime stages:

1. Dependencies are installed in the build stage.
2. TypeScript sources are compiled into scripts/.
3. Development-only dependencies are pruned.
4. Only the production dependencies and compiled scripts are copied into the final image.
5. The final image runs as the non-root node user.

The runtime command originally invoked bin/hubot. That launcher unconditionally runs npm install and npm run build, but the final image intentionally does not contain tsconfig.json or src-ts/. Consequently, a production container would fail during startup even though its compiled scripts were already present.

The Docker command has therefore been changed to launch the precompiled bot directly:

CMD ["sh", "-c", "exec ./node_modules/.bin/hubot -n \"${HUBOT_NAME:-bot}\" -a slack"]

This keeps the image immutable and prevents dependency installation or unnecessary TypeScript compilation during container startup.

Existing Hubot 14 compatibility issue

This branch inherits hubot@14.1.0 from the previously merged Dependabot changes. The Hubot upgrade was not introduced as part of this Node.js upgrade.

Although Hubot 14 supports Node.js 24, it is not compatible with several legacy components currently used by this repository:

• hubot-slack cannot be loaded through Hubot 14's ESM-based adapter loader.
• hubot-env exposes a CoffeeScript entry point that Hubot 14 cannot import directly.
• hubot-redis-brain@0.0.3 declares compatibility with Hubot 2.x.
• The existing receive and listener middleware use Hubot's older three-argument callback API, while Hubot 14 expects the newer async middleware API.
• Hubot 14 does not process the legacy hubot-scripts.json configuration, so the Redis brain and shipit scripts are not loaded through that file.

Using --legacy-peer-deps allows npm to install this dependency tree, but it does not resolve these runtime incompatibilities.

The Node.js 24 toolchain itself installs, compiles, type-checks, and runs the repository's regression tests successfully. However, full Slack bot startup remains blocked by the independently merged Hubot 14 upgrade. That dependency should either be temporarily pinned to a compatible Hubot release or migrated separately with compatible adapters, scripts, middleware, and persistence packages.

Current CI coverage and gaps

The workflow currently verifies:

• Dependency installation on Node.js 24
• TypeScript type-checking
• TypeScript compilation
• Migration and launcher regression tests
• Production Docker image construction
• Importing all compiled JavaScript modules

The Docker smoke test currently overrides the image entry point and executes Node.js directly. This allows CI to import the compiled modules without requiring Slack credentials, Redis, or other production services.

Because the real Docker command is bypassed, the test does not verify:

• The image's actual startup command
• Hubot robot initialization
• Slack adapter loading
• External CoffeeScript script loading
• Middleware registration against Hubot 14
• Redis brain initialization
• A successful connection to Slack

Therefore, a green CI run currently confirms that the Node.js and TypeScript build artifacts are valid, but it does not confirm that the complete production bot starts successfully. A separate end-to-end startup test should be added after the Hubot compatibility work is resolved.

Closes #49

[alronova]

I got the issue you are facing currently, I'd suggest you to avoid making changes related to hubot. As of now, we need to migrate from hubot to bolt as slack adapter as well. The master is broken anyways so working on hubot related changes will be useless, I'd suggest you to work on #50. I'll merge both the PRs at once.