-
Notifications
You must be signed in to change notification settings - Fork 10
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
Recommendation for the TSC: nvm in or out? #10
Comments
I agree we should discuss it. So far I have seen only one reason not to immediately bring Are there any other reasons not to accept it? The fact that |
The discussion at #5 seems to have had the following outcome:
|
That discussion was not conducted with everyone - in no way do I agree that "it should be only one". That seems needlessly restrictive. Bringing in "more than one" is not a slippery slope to "bringing in all". All we need to do is come up with criteria to apply to bringing a project in, and apply them to everyone equally. |
The take-away from that point was a consensus on standard installation patterns must be arrived at before considering inclusion of any project. |
That's definitely something we need to discuss further, because in no way do I agree that that should be a blocker for anything. Those decisions can be made in parallel along with anything else. |
I think we learned on Thursday that the criteria includes a notion of "supported by" the Foundation, and that's why we probably only want to have one, and why we felt it was too early to choose that. Also continuing the conversation at nodejs/TSC#96 (comment) to get the TSC's take. /cc @mikeal @thealphanerd |
All projects are already supported by their existing maintainers. Moving a project into the foundation does not necessarily mean anyone has to, or will, alter the amount of effort they're putting in - and in fact, getting a concrete commitment from project maintainers prior to accepting a project would be a must anyways. |
Imo the biggest drawback of nvm is that it only works on POSIX shells, so naturally it won't work in Windows cmd nor PowerShell (nor e.g. fish on Linux). There's nvm-windows which works fundamentally different than nvm. And there's ps-nvm, which afaik is the only Node version manager that runs on macOS, Linux and Windows (also has some neat features and way easier to understand code if you ask me), but of course needs PowerShell. Then there are also alternatives like n. It definitely feels hard to move one into the foundation but not the others. |
@felixfbecker moving one into the foundation now in no way prevents all of the others from moving in later. If this has to be "all version managers or none", it's going to be none - the only way this would happen is one at a time, which means someone has to be first. (I've never heard of ps-nvm, but there's also nvs, which works on all three of those platforms; also, nvm works fine on Windows in BashOnWindows/WSL) |
BashOnWindows is still very much a minority share of the Windows community. Last I checked, roughly 70% of the world is running Windows and a larger percentage of that is still on Windows 7 (which still has extended support through 2020). FWIW, I also have a posix version of nvm-windows (it's all being renamed), but have been insanely busy over the last few months. Simply not enough time to finish/release. |
Yeah, also when you are running nvm inside WSL, you’re not running it inside Windows or installing Node for Windows on Windows, you are installing Node for Linux on Linux Subsystem. It doesn’t help if you need to install Node for Windows on Windows. |
Sure. But again, the node foundation doesn't have to have as its requirement that every foundation version manager supports every supported platform; the intention would be for the foundation to guide and mentor multiple version managers, with the overarching goal of reaching the optimal cross-platform solution. |
nvm has since been moved to the OpenJS Foundation, and there is no more node foundation, so this issue is obsolete. |
As they seem to be expecting some kind of recommendation from us for this, I think it would be a good idea to discuss this.
IMO, however, this depends largely on what the Node.js foundation intends to be / not be, which seems to me to be unspecified as of yet, so my vote is to reject the question until that is settled (there'll likely be a better way to decide whether it should be accepted by the foundation then).
The text was updated successfully, but these errors were encountered: