I’m working with LocalWP and using tailpress.io for my WordPress theme development. When I try to run npm install to get my dependencies, something weird happens. The command runs but only creates empty folder structures in the node_modules directory. No actual package files get installed.
# This is what I'm running
npm install
# Expected: Full packages with files
# Actual: Empty directories only
The workaround I found is to move my theme outside the LocalWP environment, run the installation there, then move everything back. This works but it’s really tedious to do every time.
I think LocalWP’s environment setup with its own composer and nginx configuration might be interfering with npm somehow. Already tried the usual fixes like removing package.json, running npm cache clean --force, and reinstalling, but same problem keeps happening.
Anyone know what part of LocalWP’s stack causes this issue?
This happens because LocalWP runs in a virtual machine that screws up file permissions for npm. I’ve hit this with several Local sites - running npm with elevated permissions fixes it. Try sudo npm install on Mac/Linux or run your terminal as admin on Windows. The VM creates permission conflicts that stop npm from writing files during package extraction. You can also tell npm to use a different cache directory outside LocalWP with npm config set cache /path/to/different/cache before installing.
had this exact issue a few months back! the symlink handling in localwp was causing the problem. try npm install --no-bin-links instead of the regular install - fixed it for me and beats moving files around all the time.
Hit this same nightmare with LocalWP about six months back - it’s the Docker container’s filesystem screwing things up. LocalWP uses a bind mount for wp-content, and npm can’t create files properly through these mounts when installing packages. Fixed it by making npm use a different tmp directory outside the mounted volume. Just run npm config set tmp /tmp/npm-tmp before installing. This forces npm to extract packages somewhere it actually has proper access, then moves them to node_modules. Way cleaner than your workaround and works consistently across all LocalWP sites.