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

node_version_prompt should work without NVM #1946

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

kigster
Copy link
Contributor

@kigster kigster commented Sep 13, 2021

Description

Adding node prompt that does not depend on nvm and will work with other version managers as well.

Motivation and Context

There are now alternative version managers available, such as a much more streamlined volta.sh. It feels like a deja-vu of rvm to rbenv switch, all over again.

In any case, we should be able to show node version regardless of whether you are using NVM or not.

I decided not to add dedicated PREFIX variables for now, but it can be done later.

We still check if nvm prompt returns something first because the declare check is practically free, and if it returns something — we use it. Only if the output of NVM is blank do we use the new function to grab the version of NodeJS.

There is a caveat — if node is installed with the OS, eg /usr/bin/node the new function will now pick up the version of that "system" node and show it. Therefore "system" node version will now be visible in the prompt of those who added node component to their prompt. Personally, I believe this is the correct behavior, because why should we hide the system node version if that's what's available and in the PATH? We shouldn't. In fact, I think it's rather confusing that previously we wouldn't show the system node version at all.

How Has This Been Tested?

Tested locally on OS-X/bash:

* with/without NVM
* with/without VOLTA
* with/without system node

Screenshots (if appropriate):

Powerline Multiline with VOLTA version manager and no NVM:
Screen Shot 2021-09-12 at 11 46 53 PM

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • If my change requires a change to the documentation, I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • If I have added a new file, I also added it to clean_files.txt and formatted it using lint_clean_files.sh.
  • I have added tests to cover my changes, and all the new and existing tests pass.

@kigster kigster force-pushed the kig/nodejs-version branch 2 times, most recently from 5a94e66 to c612a65 Compare September 13, 2021 07:26
Adding `node` prompt that does not depend on `nvm` and will work with other version managers as well.

There are now alternative version managers available, such as a much more streamlined [volta.sh](https://volta.sh).  It feels like a deja-vu of `rvm` to `rbenv` switch, all over again.

Regardless, we should be able to show the current `node` version whether you are using NVM, VOLTA or a hot potato.

I decided not to add dedicated PREFIX variables for now, but it can be done later.

We still check if `nvm` prompt returns something first because the `declare` check is practically free, and if it returns something — we use it. Only if the output of NVM is blank do we use the new function to grab the version of NodeJS.

There is a caveat — if `node` is installed with the OS, eg `/usr/bin/node` the new function will now pick up the version of that "system" node and show it. Therefore "system" node version will now be visible in the prompt of those who added `node` component to their prompt. Personally, I believe this is the correct behavior, because why should we hide the system node version if that's what's available and in the PATH? We shouldn't.  In fact, I think it's rather confusing that previously we wouldn't show the system node version at all.

Tested locally on OS-X/bash:

    * with/without NVM
    * with/without VOLTA
    * with/without system node
Copy link
Member

@NoahGorny NoahGorny left a comment

Choose a reason for hiding this comment

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

Hi @kigster, great addition!
It seems like the lint stage is failing, so you probably need to fix that.
Other than that- I would be delighted if you could add tests for this. You can add a mock nvm/node similar to whats being done in base.theme.svn.bats
what do you think?

@gaelicWizard
Copy link
Contributor

@kigster, I opened kigster#3 which fixes the linting failure and alsö addresses @NoahGorny's suggestion. If you accept that PR, then it will automatically update this PR, which I then think is ready to merge.

@kigster
Copy link
Contributor Author

kigster commented Feb 24, 2022

@gaelicWizard Thank you so much! My apologies, I started a new job and this fell off my radar. Glad you were able to finish it!

Copy link
Contributor

@gaelicWizard gaelicWizard left a comment

Choose a reason for hiding this comment

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

The test failure with upower should be fixed in #2061. The linting error just needs a new line, suggested in my comment

@gaelicWizard
Copy link
Contributor

gaelicWizard commented Feb 25, 2022

@NoahGorny, this one seems good to go, except for tests. I'm about to overhaul the BATS infra so I'm willing to add any missing coverage at that point unless @kigster has some tests up his sleeve.

@kigster
Copy link
Contributor Author

kigster commented Feb 25, 2022

I don't have anything at the moment, like I said — new job :)

@kigster
Copy link
Contributor Author

kigster commented Mar 24, 2022

Conflicts resolved, any chance to get this merged?

@kigster
Copy link
Contributor Author

kigster commented Mar 24, 2022

Also, locally with shellcheck enabled, I don't have any issues around the lines I've changed. If the linter checks the entire file, then I am not really sure it's appropriate for me to be fixing everyone else's lint issues?

@kigster
Copy link
Contributor Author

kigster commented Mar 24, 2022

The docs CI error is the following:

ImportError: cannot import name 'environmentfilter' from 'jinja2' 
(/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/jinja2/__init__.py)

I am certain this change has nothing to do with this failure.

local node_version
if _command_exists node; then
node_version="$(node --version 2> /dev/null)"
if [[ -n ${node_version} ]]; then
Copy link
Member

Choose a reason for hiding this comment

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

This check would give a false positive when using version management shims that are common with tools like asdf

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Could you clarify? What do you mean by a false positive?

if node --version returns a non-empty output, doesn't that mean that this is the current node version? If so, why not show it in the prompt?

Copy link
Contributor

@seefood seefood left a comment

Choose a reason for hiding this comment

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

seems good, but needs a new merge from master because there are conflicts. please resolve the conflicts and I'll merge it.

@seefood seefood self-assigned this Nov 13, 2024
@seefood seefood added seems abandoned rattle the cage, and close if nobody wants to keep it going waiting-for-response labels Nov 13, 2024
@kigster
Copy link
Contributor Author

kigster commented Nov 19, 2024

Sounds good. I noticed the same problem with ruby.

Should I submit a separate PR for Ruby or include it here?

@seefood
Copy link
Contributor

seefood commented Nov 19, 2024

Sounds good. I noticed the same problem with ruby.

Should I submit a separate PR for Ruby or include it here?

new issue = new PR. thanks!

@seefood seefood marked this pull request as draft November 19, 2024 19:47
@seefood seefood removed seems abandoned rattle the cage, and close if nobody wants to keep it going waiting-for-response labels Nov 19, 2024
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.

5 participants