WHY?

[wzrdtales]

Reasoning

The reason for this friendly hard fork, was the inability to get on a common path with the original maintainer. Since he does not accept the patches in the way they were designed, like replacing an unnecessary npm call with a simple sed call, which does exactly the same but without npms overhead, whichs only reason of existence is to protect the user from himself, I was forced to friendly hard fork. It however is his right to reject the patches, just as it is mine to hard fork. Welcome to the open source world :)

Should the author ever wants to merge these change I am happy to deprecate the fork.

See for reference:

nvm-sh/nvm#1596
nvm-sh/nvm#1597

Performance bench

The whole reason of this hard fork, were significant improvements to the loadtime. So you can use nvm without screwing up your whole shell. The patches applied do not modify any behavior, but do exactly the same as the original ones. Additionally I added a --fast-reuse flag to enable an additional feature, that saves the last used version to a local file and restores this version on the next shell execution, to completely skip the versioning tree, which is ultimately the slowest path of nvm.

Original NVM

time zsh nvm.sh             
zsh nvm.sh  0,42s user 0,24s system 110% cpu 0,594 total

NVM-NG without --fast-reuse

time zsh nvm.sh
zsh nvm.sh  0,14s user 0,08s system 125% cpu 0,178 total

NVM-NG with --fast-reuse

time zsh nvm.sh --fast-reuse
zsh nvm.sh --fast-reuse  0,04s user 0,01s system 111% cpu 0,047 total