Hook System

[coreybutler]

There have been multiple requests for npm management and related workflow niceties, first noted in #26.

To resolve this, add a hooks directory, similar to how git does it. NVM4W should run any pre and post scripts for the following operations:

• install
• use
• proxy
• mirror

For anyone viewing this, I really want to keep NVM4W as slim as possible. The hook concept will allow custom functionality, but I'll likely put together several common examples, including how to use a common node_modules directory across multiple versions via symlink.

[ClementParis016]

That would be great! An hook system is flexible enough to let users do whatever scripting they want while keeping the core functionality untouched.

[aaroncalderon]

@coreybutler

I was thinking about this and I read your comment on issue #26.

So, my idea is that nvm4w does not have to manage anything. Merely, it would be ideal for nvm4w to provide the hook functionality to empower end users.

Manage npm's prefix setting ~\.npmrc

My use case would merely update the folder where I would keep the modules per node version.

1. run nvm use 10.22.1
2. have the hook for use run my script:

# <nvm_install_directory>\hocks\use\update_npm_prefix.ps1
# PowerShell
# where $paramUse is the original value parameter from the `use` command
npm set prefix `C:\dev\npm_$paramUse` -g

Other Ideas

Additionally, the concept/script could be developed further:

• definitely, it would have to update the path
  • this may have to work similarly to how nvm4w uses symlinks (this is getting more complicated by the minute)
• perhaps only to keep the modules in a folder by major (x) or major.minor (x.x) node versions
• perhaps keep a list of module names in ~\.nvm4w that will be installed every time

[coreybutler]

@aaroncalderon that is a really good example of exactly what I had in mind, i.e. users can create their own hook scripts and nvm4w will run them if they exist.

Keeping modules in directories by semver would be quite complex, since it needs to account for both 32 and 64-bit architectures... not to mention npm from older versions of Node operates very differently from modern versions (and yarn treats the structure differently too).

I'm trying to avoid dot files for the next version (see this post), but the idea of a module manifest of some kind could be incorporated into the hook system.

Thanks for sharing your thoughts!

[Copystrike]

Hey is this still being considered? Would love to see a hook system, would be super nice to have it automatically install yarn whenever I download/switch versions.

[coreybutler]

@Copystrike Not in NVM4W (which is in a feature freeze), but event hooks and native handlers are a central part of Runtime. The use case you mention is one of several common ones we're using for testing.

[Copystrike]

Awesome, @coreybutler! Can't wait to see those event hooks and native handlers in action in Runtime. By the way, I've signed up for the Runtime beta. Keep it up!