4

As a developer I want to have multiple projects that can use different versions of NODE js. Also when I checkout new project from a GIT repository I ideally want to run just one command and all things would be automated.

Given that file .nvmrc allow for automatic switching of NODE versions per directory. And given that my project is built on top of that specific version of NODE and might not work in any other.

Should I commit it to GIT?

This might be opinion based question, but I am really asking on disadvantages of doing so. Are there any risks?

--

Background:

This was like my first commit, after I started working in the new company. My ex-colleague declined that PR (without previous debate), and when I asked, he told me that its a developer responsibility to use proper version.

Well I added .nvmrc to .gitignore and used it anyways. Otherwise I would need to type nvm use xx every time I opened a new window in terminal.

Marakoss
  • 588
  • 1
  • 10
  • 24
  • Doesn't answer your question, but is [related](https://stackoverflow.com/questions/23556330/run-nvm-use-automatically-every-time-theres-a-nvmrc-file-on-the-directory) somewhat. – mnestorov Oct 07 '20 at 18:37
  • If you are all collaborating on a project then you should all work on the same version, and if the version needs to update then a file specifying that version is an ideal shared way to do it. It is not up to individual developers to guess what version is supported. The challenge seems to be bikeshedding over which package manager to use (which really needs to be team standard) and following that whether to use .nvmrc or .node-version, or just simlink them like https://dev.to/kovah/nvmrc-or-node-version-which-one-do-you-prefer-300n – Davos May 19 '21 at 23:27

1 Answers1

3

There is nothing inherently bad about specifying the version of your tool with which the project is being run (or for that matter, any project specific files as nicely discussed here), because:

  • It's clear what you are targeting, allowing you to use those features in that specific version.
  • Convenient for project setup.
  • Can be ignored (in some cases) by people who don't want to use it.
  • Does not enforce anyone to use it (like for .nvmrc).

Plenty of people and many node projects commit their .nvmrc file.

I guess what your colleague meant is one of the following (just guessing):

  • You as a programmer maintain the project and its version, not the other way around.
  • The project "shouldn't know" about what version of node you are using.
  • "Locks-in" the development of the project to one version or not allowing it to change and evolve versions in the future.
mnestorov
  • 4,116
  • 2
  • 14
  • 24
  • 1
    I would like to believe that his reasons were this clear. Yet he totally failed to explaim himself. – Marakoss Oct 08 '20 at 19:23
  • Colleagues are like that sometimes. It's important we are clear at least when we get into such situations. Also to note to the answer, many other projects in other languages have project specific files (even IDE specific files) that get committed. I would assume that committing nvmrc is quite low on the "evil" scale – mnestorov Oct 08 '20 at 19:26
  • I still dont know why it should be evil in the first place. – Marakoss Oct 09 '20 at 20:02
  • It's not evil, but some just consider it that way. – mnestorov Oct 10 '20 at 01:32
  • 2
    Those points are clear but in reply: 1. Other programmers collaborating also need to know about and help maintain the version, 2. The project includes package dependencies which do depend on the node version, 3. Lock-in aka version pinning is good for repeatable deployments - would you remove versions from package.json? Version pinning does not prevent change or evolving in the future but that can introduce package compatibility issues or breaking changes so should be done and tested in a controlled way – Davos May 19 '21 at 23:32