Install npm packages without relying on sudo

If npm install -g works only with sudo, inspect the global prefix and the path named in the error. Routine user-installed tools should have a deliberate writable destination. Elevating every install hides that ownership problem and increases the consequences of executing package code.

Give global tools a user-owned prefix

For a POSIX installation that is not managed by nvm-sh:

npm config get prefix
npm config get cache
mkdir -p "$HOME/.npm-global"
npm config set prefix "$HOME/.npm-global"
export PATH="$HOME/.npm-global/bin:$PATH"
npm install -g typescript

Add the PATH line to the configuration for your actual shell and reopen it. Use $HOME in the command rather than assuming a quoted tilde is expanded by the shell. These commands change where future global packages are installed; they do not move existing packages automatically.

Fix only the files that have the wrong owner

Inspect the reported path before changing permissions. If your personal npm cache really is $HOME/.npm and was incorrectly created as root, a scoped repair on Unix is:

sudo chown -R "$(id -u):$(id -g)" "$HOME/.npm"

Apply the same reasoning to a verified personal global prefix if it has the same problem. Do not recursively change ownership of the current directory without confirming what tree it contains, and do not change shared or system-managed directories to make an install succeed.

For a local project install, inspect its directory, node_modules, and the cache separately. Being able to write the project root does not prove every existing file beneath it has the correct owner.

Consider a version manager

A user-scoped Node version manager can keep Node and its global packages out of protected system paths. Follow the project's official installation instructions and review the installer. Once nvm-sh is installed and loaded:

nvm install --lts
nvm use --lts

nvm-sh does not support a conflicting custom npm prefix, so clean up that configuration according to its documentation when switching approaches. Its Unix shell setup is different from tools such as nvm-windows or fnm; check the platform-specific installation requirements rather than assuming none needs administrator involvement.

Why repeated elevation is a poor repair

Privileged installations can create files with ownership that later ordinary commands cannot use. Package lifecycle scripts also execute code, so their permissions and working context matter. The exact identity used by lifecycle scripts depends on npm's version and context; do not rely on a universal rule that every script always runs as root or is always safely deprivileged.

Use a consistent installation model across development and CI, and give each environment only the paths it needs to write.

FAQ

Should a project install need sudo? Usually it should run as the account that owns and builds that project. Diagnose the exact denied operation instead of elevating the entire install.

Can I install without administrator access? Often a permitted user-owned installation is possible, but organizational policy, platform requirements, and available tools still apply. A global prefix setting only helps if you already have a working Node installation.

Why is the command missing after I change prefix? Confirm the package was installed under the new prefix, inspect npm config get prefix, and check PATH in a new shell. A version manager may have changed which Node and npm executables are active.

Must the tool be global? A project-local dependency run through a package script is often easier to reproduce. npm exec can also run a tool, but may download and execute package code when it is not already available.

References

• npm permission-error guidance
• nvm-sh installation and npm prefix limitations