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

Add support for nodenv #226

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

shaun-floss
Copy link

@shaun-floss shaun-floss commented Nov 15, 2019

This will add support for nodenv to display the current Node.js version in the prompt. I used the code from rbenv section as a reference to add this functionality.

I also updated the configuration setting theme_display_nvm to theme_display_nodejs. I left one reference to the old configuration setting so it will still work for anyone who is currently using it.

@@ -861,13 +861,31 @@ function __bobthefish_prompt_desk -S -d 'Display current desk environment'
end

function __bobthefish_prompt_nvm -S -d 'Display current node version through NVM'
[ "$theme_display_nvm" = 'yes' -a -n "$NVM_DIR" ]
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure about nodenv, but running nvm every time we render a prompt is slow. That's why it's opt-in rather than opt-out, and that's also why we check $NVM_DIR and bail early, rather than calling nvm current.

I'd love to support nodenv, but I really don't want to slow down the prompt for everyone all the time to do it :)

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for responding, @bobthecow! 😃

running nvm every time we render a prompt is slow. That's why it's opt-in rather than opt-out, and that's also why we check $NVM_DIR and bail early, rather than calling nvm current.

That makes sense to me. Won't the new check/guard (right below this) ensure that we fail/bail early? 🤔

 [ "$theme_display_nvm" = 'no' ]
    and return

Also, I can add the check for $NVM_DIR to the if type -fq nvm line if that works?

Let me know what you think! 😄

Copy link
Member

Choose a reason for hiding this comment

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

My point was that expensive checks should always be opt-in, not opt-out. And I'm not sure about nodenv, but nvm is definitely expensive, so it shouldn't be on by default.

Yes, the check for $NVM_DIR should be preserved. Maybe add it to the nvm branch, something like…

if type -fq nvm
  [ -n "$NVM_DIR" ]
  or return

  # ...

Copy link
Author

Choose a reason for hiding this comment

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

Yes, the check for $NVM_DIR should be preserved. Maybe add it to the nvm branch, something like…

if type -fq nvm
  [ -n "$NVM_DIR" ]
  or return

  # ...

I updated this to what you suggested. 😃

Copy link
Contributor

@alessandro-fazzi alessandro-fazzi left a comment

Choose a reason for hiding this comment

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

Other than my inline review, I'd like to say one thing about

this should be renamed to theme_display_node to be consistent with theme_display_ruby

IMO collapsing on theme_display_node will bring to - as it is brought by your PR - a single option enabling a single function full of branch conditions. Managing the node version could be done through nvm, nodeenv, asdf, you name it. Every version manager will have its own behavior, own plugins, etc.

Taking a trip on __bobthefish_prompt_rubies function: it relies on the theme_display_ruby option and it has 3 or 4 branch conditions inside. It happens just because you have to catch what version manager is the user on and implement specific logic.

While the function __bobthefish_prompt_nvm relies on theme_display_nvm option: if a user requires to enable nvm, I haven't to scrape his system in search for what version manager he's using; thus we can go straight to the only logic. This is easier to write, easier to read, easier to change.

Obviously you're proposing to follow an already used pattern; and yes, this is a design decision. So mine is just an opinion, but I'll obviously let the author drive the direction.


BTW, if you'll go for a rename, I spot that you shouldn't leave function __bobthefish_prompt_nvm untouched: if you're going to rename the option you should rename the function too. Shouldn't you?

fish_prompt.fish Outdated

set -l node_version (nvm current 2> /dev/null)
set -l node_version
if type -fq nvm
Copy link
Contributor

Choose a reason for hiding this comment

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

This could be a problem. Using my environment as an example:

 type -f nvm                                                              373ms
type: Could not find 'nvm'

but, since I've installed an OMF plugin...

 type nvm                                                                 185ms
nvm is a function with definition
# Defined in /Users/fuzzy/.local/share/omf/pkg/nvm/functions/nvm.fish @ line 1
function nvm --description 'Node version manager'
    if test -e $nvm_prefix/nvm.sh
        if not type -q fenv
            echo "You need to install foreign-env plugin"
            return 1
        end

        fenv source $nvm_prefix/nvm.sh --no-use ';' nvm $argv
    else
        echo "You need to install nvm itself (see https://github.com/creationix/nvm#installation)"
        return 1
    end
end

As you can see I do have nvm but the binary executable is wrapped and masked by a function. This is how a lot of plugins work AFAIK.

My supposition is that type -f check could not be safe enough. Any thoughts?

Copy link
Member

Choose a reason for hiding this comment

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

Good point. In this case, type -q rather than type -fq seems appropriate.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for pointing this out! I updated it to type -q. 👍

fish_prompt.fish Outdated

set -l node_version (nvm current 2> /dev/null)
set -l node_version
if type -fq nvm
Copy link
Member

Choose a reason for hiding this comment

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

Good point. In this case, type -q rather than type -fq seems appropriate.

@@ -861,13 +861,31 @@ function __bobthefish_prompt_desk -S -d 'Display current desk environment'
end

function __bobthefish_prompt_nvm -S -d 'Display current node version through NVM'
[ "$theme_display_nvm" = 'yes' -a -n "$NVM_DIR" ]
Copy link
Member

Choose a reason for hiding this comment

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

My point was that expensive checks should always be opt-in, not opt-out. And I'm not sure about nodenv, but nvm is definitely expensive, so it shouldn't be on by default.

Yes, the check for $NVM_DIR should be preserved. Maybe add it to the nvm branch, something like…

if type -fq nvm
  [ -n "$NVM_DIR" ]
  or return

  # ...

This will make is so that the current Node.js version can be displayed
using either nvm or nodenv.

I also changed the configuration setting `theme_display_nvm` to
`theme_display_nodejs`.
@shaun-floss
Copy link
Author

Other than my inline review, I'd like to say one thing about

this should be renamed to theme_display_node to be consistent with theme_display_ruby

IMO collapsing on theme_display_node will bring to - as it is brought by your PR - a single option enabling a single function full of branch conditions. Managing the node version could be done through nvm, nodeenv, asdf, you name it. Every version manager will have its own behavior, own plugins, etc.

Taking a trip on __bobthefish_prompt_rubies function: it relies on the theme_display_ruby option and it has 3 or 4 branch conditions inside. It happens just because you have to catch what version manager is the user on and implement specific logic.

While the function __bobthefish_prompt_nvm relies on theme_display_nvm option: if a user requires to enable nvm, I haven't to scrape his system in search for what version manager he's using; thus we can go straight to the only logic. This is easier to write, easier to read, easier to change.

Obviously you're proposing to follow an already used pattern; and yes, this is a design decision. So mine is just an opinion, but I'll obviously let the author drive the direction.

BTW, if you'll go for a rename, I spot that you shouldn't leave function __bobthefish_prompt_nvm untouched: if you're going to rename the option you should rename the function too. Shouldn't you?

Thanks for reviewing and for the feedback! I ended up changing the configuration setting to theme_display_nodejs, I also update the documentation and related functions. Let me know what you think! 😃

function __bobthefish_prompt_nvm -S -d 'Display current node version through NVM'
[ "$theme_display_nvm" = 'yes' -a -n "$NVM_DIR" ]
function __bobthefish_prompt_nodejs -S -d 'Display current Node.js version'
[ "$theme_display_nodejs" = 'yes' -o "$theme_display_nvm" = 'yes' ]
or return
Copy link
Author

Choose a reason for hiding this comment

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

I left the existing configuration setting theme_display_nvm here for anyone who is currently using it. Let me know if this is okay, or if you want me to take another approach. 😃

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.

3 participants