Setting up npm global installation directory correctly

Other Questions NPM
1

I’m having trouble with npm global packages not being accessible from the command line after installation.

I installed Node.js using Homebrew on my Mac. When I tried to install eslint globally using npm install -g eslint, the installation seemed to work fine but I can’t run the eslint command afterward.

Here’s what happened:

$ npm install -g eslint
+ [email protected]
added 112 packages in 8.52s
/usr/local/share/npm/bin/eslint -> /usr/local/share/npm/lib/node_modules/eslint/bin/eslint.js

But when I try to use it:

$ eslint myfile.js
bash: command not found: eslint

The issue is that /usr/local/share/npm/bin isn’t in my PATH environment variable.

My questions are:

  1. Should I manually add /usr/local/share/npm/bin to my PATH in my shell configuration file?
  2. Is there a better way to configure npm’s global installation path so it uses a directory that’s already in my PATH?
  3. Why doesn’t Homebrew’s Node.js installation automatically set this up correctly?

I’m wondering if there’s a proper way to configure npm’s prefix setting or if I should be using a different approach entirely. I want to avoid having to manually create symlinks for every global package I install.

2

This PATH issue hits everyone eventually - classic headache. Don’t bother wrestling with npm global installs and PATH configs. Skip that whole mess.

What you’re seeing is just the start. Fix PATH today, you’ll hit version conflicts and dependency hell tomorrow when juggling multiple projects with different tool requirements.

I handle tooling automation completely differently now. Need linting, formatting, or dev tools across projects? Set up automated workflows that don’t depend on local global installs.

Example: create a workflow that runs eslint automatically when you push changes, or set up automated code quality checks in the cloud. No more wondering if eslint’s installed globally, what version you’re running, or how PATH is configured.

Automation means your dev pipeline works the same on any machine, regardless of npm setup. Add other tools easily, run multiple checks in parallel, get consistent results every time.

Latenode makes this straightforward to set up. Automate your entire dev workflow without the local tooling headaches.

3

The npm prefix thing works, but honestly just use nvm instead. It kills all these headaches completely. When you install Node through nvm rather than Homebrew, global packages just work - no PATH wrestling needed. I hit the same wall with Homebrew’s Node install. Switched to nvm and boom, problem gone. No config needed. Everything lives in ~/.nvm and it handles your shell profile automatically. Just run nvm install node and global packages work instantly. Bonus: you can swap Node versions easily when projects need different ones. Takes maybe 10 minutes to switch from Homebrew to nvm, saves tons of frustration later.

4

Just add /usr/local/share/npm/bin to your PATH in ~/.zshrc or ~/.bash_profile. The npm prefix trick works but can break other stuff. Adding export PATH="/usr/local/share/npm/bin:$PATH" is cleaner and won’t mess with your existing setup. Homebrew doesn’t handle this since npm manages its own global packages separately from the node install.

5

Been through this nightmare more times than I want to remember. Everyone’s suggesting PATH fixes or switching to nvm, but they’re missing the real issue.

Yeah, those solutions work short-term. But what happens when different projects need different linting rules? Or your team uses different formatters? You get a mess of global packages fighting each other.

I ditched npm globals completely. Instead of installing eslint globally and crossing my fingers PATH cooperates, I just automate the linting. Set up workflows that run eslint on your code automatically - no local installs needed.

This scales so much better. New project with different rules? Fine. Working on a fresh machine? Doesn’t matter. Code gets checked the same way every time.

I do all my dev automation like this now. Latenode makes it dead simple to build these workflows that just work, no matter what your local npm looks like.

6

Had this exact problem when I switched from the Node.js installer to Homebrew. Just change npm’s global prefix to a directory that’s already in your PATH. Run npm config set prefix /usr/local and you’re done. This makes npm install global packages to /usr/local/bin instead of /usr/local/share/npm/bin. Since /usr/local/bin is already in your PATH on macOS, your global packages work right away. You might need to reinstall eslint globally after changing the prefix. Homebrew doesn’t fix this automatically because it only manages Node.js itself, not npm’s config. I’ve used this setup for months across different projects - way more reliable than messing with PATH variables.