Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There should be a clear(er) vision for nvm #587

Open
koenpunt opened this issue Nov 29, 2014 · 2 comments
Open

There should be a clear(er) vision for nvm #587

koenpunt opened this issue Nov 29, 2014 · 2 comments
Assignees

Comments

@koenpunt
Copy link
Contributor

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?

@koenpunt koenpunt changed the title There should be clear vision for nvm There should be a clear(er) vision for nvm Nov 29, 2014
@ljharb
Copy link
Member

ljharb commented Nov 30, 2014

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).

@ljharb ljharb self-assigned this Nov 30, 2014
@creationix
Copy link
Collaborator

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.

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

No branches or pull requests

3 participants