[BUG] npx fails to find local packages in project directory when using fnm

[Liu-Eroteme]

Description

Update:

This seems to have been caused by an ampersand in a parent directory name

---

Old:

When using fnm to manage Node.js versions, npx fails to find locally installed packages within a specific project directory, but works correctly outside of it. This issue seems to be related to how fnm manages environments, even when not explicitly switching Node.js versions.

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

npx fails with an error suggesting it's looking in an incorrect location:
Error: Cannot find module 'C:\Users\[Username]\projects\work\typescript\bin\tsc'

Relative to the current project directory, this incorrect path would be:
..\..\typescript\bin\tsc

Expected Behavior

npx should find and use the locally installed TypeScript package. Specifically:

1. npx should look for the TypeScript binary in the project's local node_modules\.bin directory.
2. The expected path should be relative to the current project directory: .\node_modules\.bin\tsc
3. If not found locally, npx should then check global installations or offer to install the package.

Steps To Reproduce

1. Set up a new project with npm init -y
2. Install TypeScript locally: npm install typescript --save-dev
3. Run npx --package typescript tsc --version inside the project directory

Environment

• OS: Microsoft Windows 11 Enterprise (Version 10.0.22631.0)

• fnm version: 1.37.1

• Node.js version: v20.16.0

• npm version: 10.8.3

• npm configuration

  •   ; node bin location = C:\Users\[Username]\AppData\Local\fnm_multishells\49976_1724995493449\node.exe
      ; node version = v20.16.0
      ; npm local prefix = C:\Users\[Username]\projects\work\scripts_&_tests\ticket_archival
      ; npm version = 10.8.3
      ; cwd = C:\Users\[Username]\projects\work\scripts_&_tests\ticket_archival
      ; HOME = C:\Users\[Username]
      ; Run `npm config ls -l` to show all defaults.
    

Additional Information

• npm exec -- tsc --version works correctly
• npx works correctly outside the project directory
• FNM_MULTISHELL_PATH changes when entering the project directory:
  • Outside project: C:\Users[Username]\AppData\Local\fnm_multishells\30700_1724997723699
  • Inside project: C:\Users[Username]\AppData\Local\fnm_multishells\12808_1724997731298
• No .nvmrc, .node-version, or .fnmrc files are present in the project or parent directories (confirmed with recursive search)
• Issue persists even with --no-install flag
• The project's node_modules.bin directory contains the correct TypeScript binaries
• fnm's --use-on-cd option is disabled in the PowerShell profile

Troubleshooting Steps Taken

• Verified npx version matches npm version (10.8.3)
• Checked for presence of .npmrc, .nvmrc, .node-version, and .fnmrc files (none found)
• Compared fnm environment variables inside and outside the project directory
• Confirmed that TypeScript is correctly installed in the project's node_modules
• Attempted to use npx with --no-install flag (same error)
• Verified that npx works correctly for other packages (e.g., cowsay)

Possible Causes

The issue could be related to how fnm is managing Node.js environments and how npx is resolving local dependencies, especially in the context of Windows installations using fnm. Even though version switching on directory change is disabled, fnm appears to be modifying the environment when entering the project directory. However, the core problem might lie in how npx interacts with this modified environment on Windows, particularly its method for resolving local package paths. The fact that npx is looking in "../../" suggests a potential incompatibility or bug in npx's path resolution logic when used with fnm-managed Node.js installations on Windows.

This could be an npx-specific issue that hasn't been thoroughly tested with Windows fnm setups, rather than a problem with fnm itself. Any insights into this behavior, particularly from those familiar with npx's internal workings on Windows or its interactions with alternative Node.js version managers, would be greatly appreciated. Additionally, suggestions for further troubleshooting or workarounds would be very helpful. Thank you for your time and assistance in investigating this issue.

[Liu-Eroteme]

Update: Root Cause Identified - Ampersand in Directory Name

After further investigation, I've identified the root cause of the issue, which is different from what I initially thought. The problem is caused by an ampersand (&) in a parent directory name, which npx seems unable to handle correctly on Windows.

Specific findings:

1. The issue occurs with or without fnm installed.
2. It's reproducible on Windows 11 with npm/npx 10.8.3.
3. The problem is triggered by having an ampersand in any parent directory name of the project.

Steps to reproduce:

1. On Windows 11, create a directory with an ampersand in its name (e.g., "scripts_&_tests").
2. Create a subdirectory inside it.
3. Run npm init -y in the subdirectory.
4. Attempt to use npx in this subdirectory.

Expected behavior:

npx should correctly resolve paths regardless of special characters in parent directory names.

Actual behavior:

npx fails to resolve the correct path, instead using the last directory above the one containing the ampersand.

Workaround:

Renaming the parent directory to remove the ampersand resolves the issue (e.g., changing "scripts_&_tests" to "scripts_and_tests").

Given the updated findings, it is clear that the issue is tied specifically to how npx handles paths (on Windows?), particularly when special characters like ampersands are involved in directory names. This problem is unrelated to fnm, counter to what i initially assumed, and could instead highlights a potential bug in npx's or even nodeJs's path resolution logic.
Considering this, it may be prudent to open a new issue in the npm/cli repository to address this specific case.

I regret any confusion caused by the initial misdiagnosis and would appreciate your guidance on the following:
Should I proceed with submitting a new issue?
Additionally, is this a known issue, or could it point to a broader problem within Node.js?