-
-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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
remove npm dependency for prefix check #1597
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also fix the indentation.
nvm.sh
Outdated
|
||
declare -a npmrcs=("." "$HOME") | ||
|
||
for npmrc in "${npmrcs[@]}"; do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
declare
is also bash-specific; nvm requires POSIX.
nvm.sh
Outdated
else | ||
nvm_err "Run \`$NVM_COMMAND\` to unset it." | ||
|
||
declare -a npmrcs=("." "$HOME") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is bash-specific syntax; nvm requires POSIX.
yeh, changed it just submitted the local version I have running though :) |
nvm.sh
Outdated
fi | ||
done | ||
|
||
if [[ -n $NVM_NPM_PREFIX ]]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
double brackets are bash-only syntax; it's not in POSIX.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
got it looking at it
local npmrcs=". $HOME" | ||
|
||
for npmrc in $npmrcs; do | ||
if [ -f "${npmrc}/.npmrc" ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what I do like about this PR in particular is adding this npmrc
check.
What would you think about adding this check prior to the npm config get prefix
check? That would enable users to get a faster warning when things were broken, pointing them at the exact file that needed to be modified - and it'd still go through the npm config
check if this grep passed.
That would also serve as a more iterative approach towards removing or bypassing the config check altogether (which I haven't agreed to yet).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well yes, but in that case if I understand your intention right npm config get prefix
would be called for every start again. Then we're were we started. But as additional check yes, that could tell the user which config is the nasty one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes; and it'd be a further thing that wouldn't have to be removed or bypassed even if the npm config
call was.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case this information is alrready there as we can just set a variable to the current npmrc value before the break statement and use that below in the error message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So added the suggested error here https://github.com/creationix/nvm/pull/1597/files#diff-e1e8e036966ad5aaf7709712cd5d8ee3R2115
ea34a86
to
d0dca5f
Compare
d0dca5f
to
be18696
Compare
So as there has been a 2 day silence since the last time, how may we continue on this matter? |
My comment above is basically saying that I'd like to add an additional early |
@ljharb That eliminates the whole sense of the PR and I don't think it is quite healthy to stop the discussion here. So what would be needed to actually move forward and resolve this discussion to an actual solution that is benefitial for all of us? So for you as maintainer and the users not suffering from slow startups anymore. |
As I've said many times; the slowdown is absolutely worth it to ensure the prefix check continues. I'm very enthusiastic about ways to improve the speed, however - and my belief is that adding your npmrc check, and then also adding an env var check, while leaving the prefix check intact for the time being will be a very useful test to see if there are any cases the prefix check is still required for. However, I'm not going to remove it lightly - it's been there, with the slowdown, for 2 years now. If you can't use nvm with that check, then for the time being, you can't use nvm - but I hope we can come up with a healthier long term plan than that. |
So you made your position clear, so we wont come at any time to any decision in this scenario.
Your suggestion, as you said, it have been 2 years now. So given your attitude towards this, it seems like the only solution would be if npm would either rewrite a whole lot of their library to actually act fast again. Or at least move the configuration part into a separate library and do it just for this part. So if you have anything concrete on your mind, I will be happy to hear your opinion how a long term plan could look like. |
Btw. I have been looking at the whole nvm script a bit more deeply to look for any other opportunities, maybe we can at least talk about adding a fast path when respawning a shell. Just quickly pushed a first version, which is not really complete (as it would currently not respect the default alias at all and just gets the last used version from the use branch, that would need to be added though) and just a first that works, here is the commit wzrdtales@ca95a3f. I really wondered why the use logic is being used to always find the version stored under the alias. Is there any reason that nvm does not just stores it default config state somewhere and reuses it? I can also open another issue for this later. |
The default state is PWD-dependent, and since the default alias is stored on disk as well, it could change at any time, out-of-band from nvm. It always has to be read freshly from disk to ensure it's accurate. |
@ljharb How is it PWD dependent? Talking about .nvmrc? A check against the default alias if it deviates shouldn't be that hard to add though. |
Yes, .nvmrc. |
Got it, Also not a problem in that case, just checking against So anything else you could think of, that would possibly cause issues when a fast path like this is added, which falls back to the current methodoligy as soon as the alias/default deviates or .nvmrc was found? |
I don't think so - I'm all for adding fast paths! As long as they're not sacrificing correctness by solely bypassing slow paths :-) |
This was obviated by #2317. |
For description see reference.
Refers to #1596
Fixes #1596