-
Notifications
You must be signed in to change notification settings - Fork 14
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
Which Switching Scopes to support by an official solution? #4
Comments
There's quite a few different scopes for setting a version requirement, that I can think of:
pro UXI've found per terminal and per directory to be the most useful, as per-terminal is imperative-ish but temporary (if you want to try your app with a different version), while per-directory is declarative and persistent (the default version per app). I think the great advantage of per-directory settings is that you don't need to remember to change your global node version when your change to another project, the switching is automatic, but defined in a declarative fashion per directory, just like your dependencies, and your build/test scripts, (possibly in the package.json, where there is already a corresponding field). IMO that's very powerful. pro simplicityHowever, the downside of this feature is that it's not easy to implement consistently across operating systems. It could also be argued that, rather than wait for a high-end solution to be built, it's better to work on a simple solution that may require more cognitive load from the down-stream developer. I see both sides while leaning more towards pro UX |
@jasongin put together a table at https://cdn.rawgit.com/jasongin/cf9f64dd2739d78412bb9410701bf166/raw/69d48e0774f43280763eb7bb7175e930ab3e9f33/NodeVersionManagers.html comparing the various scopes settable by current version managers. It might be helpful to this discussion. |
It's not so bad. For nvs I'm currently developing automatic per-directory switching. (It already supports the other 3 scopes.) For Windows PowerShell I've got it working now by hooking PowerShell's prompt function. I plan to implement the equivalent for POSIX using the same approach as nodengine. Windows Command Prompt does not offer any integration point though. Of course any automatic switching feature should be optional, as not everyone wants things to happen without an explicit command. |
@jasongin Interesting! I implemented per-directory switching via a binary shim in nodist, because I didn't want to / couldn't hook into |
This is a good breakdown. The first two scopes seem to be the common denominator. The third and fourth seem more a matter of opinion. I also see the value of both sides, but I lean pro simplicity. |
@coreybutler In fact, the second is the one that nobody seems to be really addressing currently - |
@ljharb - I respectfully disagree. Before version managers existed, the only choices were the first two. In other words, you don't need 3 & 4 to accomplish version management. nvm-windows does support per-user, but defaults to systemwide. It's an option in the installer. |
@coreybutler I think the popularity of I don't think a single switching mechanism or just one (or even 2) of those four scopes will ever satisfy everyone's needs. I'd suggest that any converged solution we work on must cover at least the first 3 of those scopes, and ideally all 4. |
@coreybutler you may be right that the creation of nvm created the third and fourth - but they are now, unarguably, absolutely critical use cases that must not be ignored. |
@ljharb - I'm not suggesting we ignore options 3/4, I'm suggesting they be optional features that can be turned on. In other words, the default should only enforce what's actually necessary to perform version management, with the option to turn on extra features. |
There are a number of benefits with having the default be per-shell instead of being systemwide. |
I agree that strictly speaking "you don't need 3 & 4 to accomplish version management" or version switching. However, I believe that a version manager (just as any tool; especially an official one) should address the needs of its users. To elaborate on why I'm leaning towards UX: I'd argue that while downstream developers might want a way to somehow quickly uninstall one and install another version when they work on another project (which is equivalent to 1), what they actually need is a way to use multiple versions at once or even set a default version per project. I also agree that 1/2 make sense in certain cases and should thus be part of an official solution, however I think 3/4 should be provided as well. @ljharb Could you elaborate on the benefits of 3 to be the default? |
Before we dive into discussions on which language/framework to use, I think we should have a clear set of features that we want to offer.
The text was updated successfully, but these errors were encountered: