Gemset Like Feature in NVM

adil-appifytech commented 7 years ago

What's the feature?

Project based global packages.

What problem is the feature intended to solve?

Lets say I have an angular 2 project which was created and managed with Angular CLI 1.0.0 and for some reasonThat Angular CLI project has been updated to 2.0.0. This updated packages do everything based on Angular 4, which is problem for our older project. So have these global CLI's based on project would help us manage that.
Following article have also tried to explain this pain (https://www.sitepoint.com/solve-global-npm-module-dependency-problem/)

Is the absence of this feature blocking you or your team? If so, how?

It is blocking us doing experiments on new packages/frameworks and also keep working on existing projects.

Is this feature similar to an existing feature in another tool?

In RVM, you have Gemsets which help you achieve the same goal.

ljharb commented 7 years ago

The proper best practice in the node/JS ecosystem is to never install anything globally, and to have the angular CLIs installed locally per-project, and use npx and npm run-scripts to invoke them.

ljharb commented 7 years ago

(This is also a duplicate of #290, which has relevant discussion)

rubyrider commented 5 years ago

Is there luck to merge this feature in near future?

ljharb commented 5 years ago

@rubyrider there's nothing to merge, and also https://github.com/nvm-sh/nvm/issues/1629#issuecomment-336602265

UniverseHan commented 5 years ago

Thank you for your response and your opinion about the global npm package.

Yes, you are right. I totally agree with

The proper best practice in the node/JS ecosystem is to never install anything globally

But sometimes it would be needed. You may want to configure your test environment or learning environment. It would be painful if you have to create install the same CLI for every very small test project. Using npx command for every fresh project is slow and also painful. Some developers may want some environments, for example, it could be for vue, react, just node, test.

Sometimes installing GCP CLI or AWS CLI for a project may be non-sense or uncomfortable.

The main purpose of nvm, I mean using different node version, also break the best practice of the NodeJS ecosystem. To satisfy that ecosystem you would be better to use docker to configure NodeJS env for each project.

But I think there is a proper reason for using nvm. It helps us to develop much easier with different globally installed nodejs. So for the same reason, having different environments that have globally installed NodeJS packages is more convenient I think.

My point is there are many packages to be installed globally and not to install in projects package.json. There is a need for gemset like feature. Finally features like the alias which is present to support that need.

ljharb commented 5 years ago

In my experience, it is not painful to install the same set of N dev deps in any number of projects - I have 200-300 on my machine; they all have eslint and a host of others installed, and it's of negligible pain to install them all the first time when i create a new project, and it avoids immeasurable pain when I want to update them later without breaking all the others.

nvm alias works if you're able to have different node versions - eg, you could have v10.0.1 and v10.0.2 aliased to different things - but clearly, not if you need them to be the same (but have different global packages).

To be honest, I'm still not clear on a concrete use case here. Even with GCP or AWS, a specific project needs to be able to track which version of the tools it's being used with.

UniverseHan commented 5 years ago

Yes, It's reasonable to specific project needs to be able to track which version of the tools it's being used with. But if the project owner or team does not allow include any GCP like a package in package.json? How could we handle it?

I think nvm is a tool that helps developers but not the tool forcing some convention.

Supporting that situation is more natural than not supporting because it's not a best practice.

ljharb commented 5 years ago

If the project owner or team doesn’t allow GCP in package.json, then it sounds like using the project with GCP isn’t allowed - that’s a human problem with a human solution, not something nvm needs to address.

Helping developers subvert their team or company’s wishes isn’t helping developers.

UniverseHan commented 5 years ago

OK, I understood what you mean.

But It's not a subvert. Any developers can deploy or use some project that doesn't want includes GCP package.json. The project owner could allow someone to deploy any environment to use any CLI for that project while they don't want to depend on any CLI tools. It is also unnatural CLI is a dependency on any project as any IDE setup does.

But anyway. You don't have any plan to support this feature even in the future.

Got it.

ljharb commented 5 years ago

I'm not saying I won't support it; I'm saying that so far I don't see any use cases for it.

Anything that any developer can use on a project, every developer on the project should be able to use - thus, it should be in package.json, not globally installed.

UniverseHan commented 5 years ago

Hmm, It's a little bit hard to understand why do you think things what is not dependency should be in dependency in package.json?

In my case, I don't want to include CLI dependency in my package.json but some times I want to use it for some reason. Another reason why it's unnatural is that we can't expect any test environment and can not expect which tools to be declared in package.json. Because we can not expect all of the environments wherein project used.

ljharb commented 5 years ago

Anything that interacts with the project in any way is a dependency, and should be in package.json.

Could you help me understand which tool doesn't interact with a project, and thus should be global?

UniverseHan commented 5 years ago

Do you think IDE env setup for a project should be its dependency? Maybe not. But it interacts with project.

ljharb commented 5 years ago

IDEs are developer-specific, and not installed via npm.

Do you have a concrete use case for global packages, installed via npm, that are not project-specific, and that also require more than one entirely distinct set of global packages, but on an identical node version?

UniverseHan commented 5 years ago

As said the CLI. I think it's just a tool, not a dependency. Whether using CLI or not is also developer-specific I think.

The reason why I don't think the CLI is not a dependency is that any project can run without CLI. But a project can not run without dependency. If the project could be run without any dependency that dependency should be removed in the dependency declaration in the package.json

ljharb commented 5 years ago

Which CLI? I'm looking for specific examples.

Also, note that "run" includes "ongoing maintenance", not just "the server starts and tests pass".

UniverseHan commented 5 years ago

vue-cli, react-cli, AWS CLI anything.

For example, Some vue projects can be maintained without vue CLI. vue-cli just helps developer to manage the project much easier.

ljharb commented 5 years ago

How are those not specific to a project?? The exact version of all of those things is highly coupled to the codebase.

ljharb commented 5 years ago

That some devs might choose not to use them is irrelevant - if they do choose to use them, they need to use the right version.

UniverseHan commented 5 years ago

By your point of view. everything is dependency os, nodejs, some database but they are not in package.json.

event nodejs version shole not be installed globally. But nvm does.

ljharb commented 5 years ago

Yes, that's true - but "platform" is a reasonable precondition. Everything else isn't.

Taking my philosophy to a logical extreme doesn't invalidate it, it's just a logical fallacy :-)

UniverseHan commented 5 years ago

I partially agree with your idea. It could make sense. It is just a different perspective.

(Thank you for your effort to listen to my opinion)

Let me take a time to think about your philosophy so I will come back to this thread :)

UniverseHan commented 5 years ago

@ljharb Hello. How about this circumstance? Sometimes I want cerate vue project using vue-cli. I also may want to create react project using create-react-app. These can not be included in package.json because the project would not be created yet. I would want to separate that global node modules for vue from react dev tool set.

I want change nvm context for react, vue or some other nodejs dependent project.

So Is this scenario enough to create gemset like feature in nvm?

If you agree with my thought, I would like to contribute with this feature.

ljharb commented 5 years ago

@UniverseHan npx vue-cli - you wouldn't install it globally since you'd always likely want to create a new app with the latest version.

nvm-sh / nvm