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

remove npm dependency for prefix check #1597

Closed
wants to merge 8 commits into from

Conversation

wzrdtales
Copy link

For description see reference.

Refers to #1596
Fixes #1596

Copy link
Member

@ljharb ljharb left a 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
Copy link
Member

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")
Copy link
Member

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.

@wzrdtales
Copy link
Author

yeh, changed it just submitted the local version I have running though :)

nvm.sh Outdated
fi
done

if [[ -n $NVM_NPM_PREFIX ]]; then
Copy link
Member

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.

Copy link
Author

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
Copy link
Member

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

Copy link
Author

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.

Copy link
Member

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.

Copy link
Author

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wzrdtales wzrdtales force-pushed the removeNpmForPerformance branch 2 times, most recently from ea34a86 to d0dca5f Compare August 26, 2017 23:56
@wzrdtales
Copy link
Author

wzrdtales commented Aug 28, 2017

So as there has been a 2 day silence since the last time, how may we continue on this matter?

@ljharb
Copy link
Member

ljharb commented Aug 28, 2017

My comment above is basically saying that I'd like to add an additional early npmrc check; but that I'm not comfortable removing the npm config get prefix call at this time. Are you willing to reduce this PR to just that additive change?

@wzrdtales
Copy link
Author

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

@ljharb
Copy link
Member

ljharb commented Aug 28, 2017

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.

@wzrdtales
Copy link
Author

So you made your position clear, so we wont come at any time to any decision in this scenario.

but I hope we can come up with a healthier long term plan than that.

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.

@wzrdtales
Copy link
Author

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.

@ljharb
Copy link
Member

ljharb commented Aug 28, 2017

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.

@wzrdtales
Copy link
Author

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

@ljharb
Copy link
Member

ljharb commented Aug 28, 2017

Yes, .nvmrc.

@wzrdtales
Copy link
Author

wzrdtales commented Aug 28, 2017

Got it, Also not a problem in that case, just checking against nvm_rc_version before using the stored state.

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?

@ljharb
Copy link
Member

ljharb commented Aug 29, 2017

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

@ljharb
Copy link
Member

ljharb commented Sep 29, 2021

This was obviated by #2317.

@ljharb ljharb closed this Sep 29, 2021
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

Successfully merging this pull request may close these issues.

Is there any reason to keep using npm config get prefix?
2 participants