There should be a clear(er) vision for nvm

[koenpunt]

I noticed that features that were previously (read; around 2011) were implemented (c060a28) removed (8dad534) and later reimplemented (5342b6a).

And there are probably more examples to be given, just like this one.

What I do know is that @creationix wanted to keep nvm lean, and it's obvious that nvm is way over lean at this point.

So I think the vision of nvm should be formulated in some way, to keep development on track.

@ljharb what do you think?

[ljharb]

Certainly with respect to curl or wget, I'd prefer to settle down over time on a single installation method, and that's core to nvm update in #400. In addition, over time, I'd like to come up with a way to remove the need for the majority of nvm to be shell-portable, since that will also drastically simplify code paths and testing overhead.

In general, I'm not afraid of adding features, as long as it doesn't add too much complexity. Overall, I feel that the features added over the last year or two have actually helped simplify the code paths and add test coverage, even as they've increased the codebase size.

It's also worth noting that node and the community itself have changed a great deal since 2011, so I think it's totally appropriate for the featureset of nvm to evolve along with them.

As I see it, nvm's vision is essentially to provide a command-line interface to manage multiple versions of node … including making installation and switching easy, running single commands as an arbitrary version of node, and facilitating upgrading one version of node to another (maintaining global packages etc).

[creationix]

I'll be honest. One of the reasons I like to keep my projects lean is because I have very limited resources in maintaining them. If the scope is minimal, there is less to worry about and quality doesn't suffer.

But since I don't maintain nvm anymore, that's much less of an issue.

As far as code cleanup, I still think we should move the majority of the code into a single known scripting language, maybe even node itself and only source bash/zsh/fish/whateversh files for things that can't be done inside the node logic. For bootstrapping we still have the same problems of curl vs wget, but there is a much smaller problem to solve with those constraints. Once you download and install a known version of node the bootstrap is done and all logic can be moved into javascript.

If node is too heavy (there is substantial cost so spawning up node processes on demand, especially on slower arm devices), I've been recently working on some faster runtimes based on luajit and duktape that would make for great scripting languages for the bulk of nvm. Even bash itself could be used for most logic, it just doesn't have native ability to download tarballs over https.