Skip to content

Conversation

@pkuczynski
Copy link
Collaborator

@pkuczynski pkuczynski commented Oct 2, 2025

Description of change

Simplifies node version management and upgrades burden. Ensures developers (contributors) use the same node version (some currently used dev dependencies require older versions of node).

Pull-Request Checklist

  • Code is up-to-date with the master branch
  • This pull request links relevant issues as Fixes #00000
  • There are new or updated unit tests validating the change
  • Documentation has been updated to reflect this change

Summary by CodeRabbit

  • Chores

    • Standardized Node.js version management across CI/CD and tooling by switching to a single, centralized project version file; CI now reads that file and treats it as part of change detection.
  • Documentation

    • Updated developer setup to recommend using the centralized Node version and listed common auto-switching tools and usage guidance.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 2, 2025

Walkthrough

GitHub Actions workflows now read Node.js version from a new .nvmrc file instead of using a hardcoded 20. A .nvmrc file with 20 was added and DEVELOPER.md was updated with guidance to use the .nvmrc version.

Changes

Cohort / File(s) Summary
GitHub Actions Workflow Updates
​.github/workflows/commit-validation.yml, ​.github/workflows/preview.yml, ​.github/workflows/publish-package.yml
Replaced node-version: 20 with node-version-file: .nvmrc in actions/setup-node@v5 steps across these workflows; behavior otherwise unchanged.
Node Version Configuration
.nvmrc
Added new .nvmrc containing 20 to centralize the Node.js version.
Developer Documentation
DEVELOPER.md
Replaced "Installing NPM Modules" with a "Node" section and added guidance to use the Node version from .nvmrc (mentions fnm, zsh-nvm, asdf auto-switching); minor punctuation/text tidy in Running Tests Locally.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

  • Mostly consistent, small configuration edits across workflow files.
  • New .nvmrc is a one-line addition; docs change is non-functional prose.

Possibly related PRs

Suggested reviewers

  • alumni
  • OSA413
  • naorpeled
  • sgarner

Poem

🐰 No more the twenty hardcoded in stone,
Now .nvmrc claims the version throne!
Workflows sip the number from one tiny file,
Docs whisper autoswitch with a joyful smile—
A small hop toward consistency, neat and known.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title directly and clearly summarizes the main change: introducing .nvmrc to control Node.js version for both development and CI environments.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4b9fee7 and 7ad3264.

📒 Files selected for processing (1)
  • .github/workflows/commit-validation.yml (4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/commit-validation.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)
  • GitHub Check: tests-linux (18) / better-sqlite3
  • GitHub Check: tests-linux (18) / mysql_mariadb_latest
  • GitHub Check: tests-linux (18) / postgres (14)
  • GitHub Check: tests-linux (18) / sap
  • GitHub Check: tests-linux (18) / postgres (17)
  • GitHub Check: tests-linux (18) / oracle
  • GitHub Check: tests-linux (18) / sqlite
  • GitHub Check: tests-linux (18) / mysql_mariadb
  • GitHub Check: tests-linux (18) / mongodb
  • GitHub Check: tests-windows / better-sqlite3
  • GitHub Check: tests-windows / sqljs
  • GitHub Check: tests-windows / sqlite
  • GitHub Check: Analyze (javascript-typescript)

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

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

@pkg-pr-new
Copy link

pkg-pr-new bot commented Oct 2, 2025

typeorm-sql-js-example

npm i https://pkg.pr.new/typeorm/typeorm@11708

commit: 7ad3264

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
DEVELOPER.md (1)

5-9: Fix broken table-of-contents link.

The TOC still points to #installing-npm-modules, but the heading was renamed to ## Node, so the link is now dead. Please update the TOC entry to keep the navigation working.

Apply this diff:

-* [Installing NPM Modules](#installing-npm-modules)
+* [Node](#node)
+* [Installing package dependencies](#installing-package-dependencies)

Also applies to: 53-64

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2446bd0 and df1f0ce.

📒 Files selected for processing (6)
  • .github/workflows/commit-validation.yml (3 hunks)
  • .github/workflows/preview.yml (1 hunks)
  • .github/workflows/publish-package.yml (1 hunks)
  • .github/workflows/tests-linux.yml (1 hunks)
  • .nvmrc (1 hunks)
  • DEVELOPER.md (2 hunks)
🧰 Additional context used
🪛 actionlint (1.7.7)
.github/workflows/commit-validation.yml

75-75: input "base-node-version" is typed as number by reusable workflow "./.github/workflows/tests-linux.yml". string value cannot be assigned

(expression)


75-75: property "outbputs" is not defined in object type {outputs: {base-node-version: string; node-versions: string}; result: string}

(expression)


81-81: input "node-version" is typed as number by reusable workflow "./.github/workflows/tests-windows.yml". string value cannot be assigned

(expression)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Analyze (javascript-typescript)

Copy link
Collaborator

@gioboa gioboa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, nice improvement 🙌

alumni
alumni previously requested changes Oct 3, 2025
Copy link
Collaborator

@alumni alumni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not base the versions run in CI on any .nvmrc file.

@pkuczynski
Copy link
Collaborator Author

Let's not base the versions run in CI on any .nvmrc file.

Why not?

@alumni
Copy link
Collaborator

alumni commented Oct 3, 2025

@pkuczynski see the other comment:

I'm not sure this is okay, since we want to change the way we run the CI in the next version.

I had to write some text to block the merge of the PR :P

Whatever is in the master branch is here because we wanted to introduce minimal changes. We only want to merge the existing PRs that fix bugs to this branch.

Any project setup changes should not be done here, but in the next branch.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between df1f0ce and 3bc55ea.

📒 Files selected for processing (2)
  • .github/workflows/commit-validation.yml (3 hunks)
  • DEVELOPER.md (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • DEVELOPER.md

# Conflicts:
#	.github/workflows/commit-validation.yml
#	.github/workflows/preview.yml
@pkuczynski
Copy link
Collaborator Author

I had to write some text to block the merge of the PR :P

🤦‍♂️

Whatever is in the master branch is here because we wanted to introduce minimal changes. We only want to merge the existing PRs that fix bugs to this branch.

Seems that other maintainers are of a different opinion, since they already approved the PR...

Any project setup changes should not be done here, but in the next branch.

This setup immediately helps people trying to come up with a bugfix. The changes in next are minimal and I can promise to you, I can can/will come up with PR changing the 18,20 to 20,24...

Question is rather: is this a good or bad change? I think its good because it lowers the entry barier for the project and ensures control of the version in a single place.

@pkuczynski pkuczynski requested a review from alumni October 3, 2025 23:26
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (1)
.github/workflows/commit-validation.yml (1)

54-61: Still assuming numeric .nvmrc breaks the matrix job.

.nvmrc can legally contain values like v20.11.1 or lts/*. In that case BASE_NODE_VERSION=$(head …) yields a non-integer and $(( BASE_NODE_VERSION - 2 )) aborts, so this job dies before emitting outputs. Please resolve the spec to an actual version and only then do the arithmetic (e.g. run actions/setup-node with node-version-file: .nvmrc, grab ${{ steps.setup-node.outputs.node-version }}, parse its major with a numeric guard, and compute the previous major from that).

-      - id: node
-        run: |
-          BASE_NODE_VERSION=$(head -n 1 .nvmrc)
-          PREV_NODE_VERSION=$((BASE_NODE_VERSION - 2))
-
-          echo "node-versions=[$PREV_NODE_VERSION, $BASE_NODE_VERSION]" >> $GITHUB_OUTPUT
-          echo "base-node-version=$BASE_NODE_VERSION" >> $GITHUB_OUTPUT
+      - uses: actions/setup-node@v5
+        id: resolve-node
+        with:
+          node-version-file: .nvmrc
+      - id: node
+        run: |
+          BASE_NODE_VERSION='${{ steps.resolve-node.outputs.node-version }}'
+          BASE_NODE_MAJOR=${BASE_NODE_VERSION%%.*}
+          if ! [[ "$BASE_NODE_MAJOR" =~ ^[0-9]+$ ]]; then
+            echo "Unable to derive major version from \"$BASE_NODE_VERSION\"" >&2
+            exit 1
+          fi
+          PREV_NODE_MAJOR=$((BASE_NODE_MAJOR - 2))
+          echo "node-versions=[$PREV_NODE_MAJOR, $BASE_NODE_MAJOR]" >> "$GITHUB_OUTPUT"
+          echo "base-node-version=$BASE_NODE_MAJOR" >> "$GITHUB_OUTPUT"
🧹 Nitpick comments (1)
.github/workflows/commit-validation.yml (1)

54-55: Update checkout to v5 for consistency.

New jobs should stick to actions/checkout@v5, same as the other jobs in this workflow. Please bump this step to the latest major.

-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v5
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3bc55ea and 4b7afab.

📒 Files selected for processing (2)
  • .github/workflows/commit-validation.yml (3 hunks)
  • .github/workflows/preview.yml (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/preview.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (20)
  • GitHub Check: tests-linux (20) / postgres (17)
  • GitHub Check: tests-linux (20) / postgres (14)
  • GitHub Check: tests-linux (20) / mysql_mariadb
  • GitHub Check: tests-linux (20) / cockroachdb
  • GitHub Check: tests-linux (18) / oracle
  • GitHub Check: tests-linux (20) / mongodb
  • GitHub Check: tests-linux (18) / mysql_mariadb_latest
  • GitHub Check: tests-linux (18) / mysql_mariadb
  • GitHub Check: tests-linux (18) / sqlite
  • GitHub Check: tests-linux (18) / sap
  • GitHub Check: tests-linux (18) / mssql
  • GitHub Check: tests-linux (18) / postgres (14)
  • GitHub Check: tests-linux (18) / postgres (17)
  • GitHub Check: tests-linux (18) / sqljs
  • GitHub Check: tests-linux (18) / better-sqlite3
  • GitHub Check: tests-windows / sqljs
  • GitHub Check: tests-linux (18) / mongodb
  • GitHub Check: tests-windows / better-sqlite3
  • GitHub Check: tests-windows / sqlite
  • GitHub Check: Analyze (javascript-typescript)

@alumni
Copy link
Collaborator

alumni commented Oct 6, 2025

I would say, let's not add unnecessary complexity by tying the workflows to the nvmrc. Let's keep things simple and easy to understand.

Regarding the nvmrc file itself, I've been oscillating between adding and not adding it over the past year. We have engines in package.json (fnm uses it by default), the main issue is rather the lack of a packageManager field. So I have no strong opinion for or against the nvmrc file itself.

@pkuczynski
Copy link
Collaborator Author

I would say, let's not add unnecessary complexity by tying the workflows to the nvmrc. Let's keep things simple and easy to understand.

My intention is to ease setup and work for the new contributors (like me myself). When I pulled the project first time, nothing worked, not even npm isntall).

I would like to be in a situation where my local run is as close as possible to CI. This way we save everyone time (and cost of CI).

Controlling both via single config file (nvmrc) seems to be a very good way to achieve that. I am not sure where do you see the complexity?

Regarding the nvmrc file itself, I've been oscillating between adding and not adding it over the past year. We have engines in package.json (fnm uses it by default), the main issue is rather the lack of a packageManager field. So I have no strong opinion for or against the nvmrc file itself.

fnm does not use it by default unless you specify optional setting --resolve-engines. More over our current setup specify 16 which does not work with some packages specified in dev dependencies.

packageManager field was related to v5 of node setup action. They implemented it in a poor way, but the fix is already coming.

@pkuczynski pkuczynski requested a review from OSA413 November 10, 2025 07:47
@pkuczynski pkuczynski self-assigned this Nov 10, 2025
Copy link
Collaborator

@gioboa gioboa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙏 it looks fine to me

@alumni
Copy link
Collaborator

alumni commented Nov 10, 2025

Sorry, but no

@coveralls
Copy link

coveralls commented Nov 10, 2025

Coverage Status

coverage: 76.433%. remained the same
when pulling 9495e6f on pkuczynski:ci/nvmrc
into 51fbcf4 on typeorm:master.

@OSA413
Copy link
Collaborator

OSA413 commented Nov 10, 2025

Controlling both via single config file (nvmrc) seems to be a very good way to achieve that. I am not sure where do you see the complexity?

The complexity comes from parsing the file and adding shifts to the node version to make it work with several versions of Node. I would save .nvmrc for new contributors, but not change the CI/CD configuration.

@alumni
Copy link
Collaborator

alumni commented Nov 10, 2025

The complexity comes from parsing the file and adding shifts to the node version to make it work with several versions of Node. I would save .nvmrc for new contributors, but not change the CI/CD configuration.

Exactly my point when I requested changes. Unfortunately the PR author does not accept feedback.

@pkuczynski
Copy link
Collaborator Author

The complexity comes from parsing the file and adding shifts to the node version to make it work with several versions of Node. I would save .nvmrc for new contributors, but not change the CI/CD configuration.

I just don't see the complexity, sorry 🤷‍♂️

Instead of manually managing node version in CI and local run, we use single point of reference and we don't have to duplicate ourselves. Even GHA actions (setup-node) support such file out of the box, so it must be not only me who see a value in such approach.

I only had to wrote really simple and small script to build the matrix... If that bothers you, I can remove that part. But I also wanted to hear some other maintainers opinion, since so far only @alumni had some considerations...

@michaelbromley
Copy link
Member

My opinion is that I prefer a number in the workflows, because I find it easier to understand. But the rest of the changes I like.

@pkuczynski
Copy link
Collaborator Author

@alumni @OSA413 @michaelbromley is it better now? Or do you want node-version-file: .nvmrc to be gone too?

@OSA413
Copy link
Collaborator

OSA413 commented Nov 11, 2025

This one is much simpler/better, let's see what others think.

@pkuczynski pkuczynski dismissed alumni’s stale review November 11, 2025 21:55

Approved by others

@pkuczynski pkuczynski merged commit 5d02f06 into typeorm:master Nov 11, 2025
64 checks passed
@pkuczynski pkuczynski deleted the ci/nvmrc branch November 11, 2025 21:55
ThbltLmr pushed a commit to ThbltLmr/typeorm that referenced this pull request Dec 2, 2025
mgohin pushed a commit to mgohin/typeorm that referenced this pull request Jan 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants