Confusing output when the root isn't an npm project, leaves a mess.

[srl295]

Hi. I'm using this action to upload a project that's not at root an npm project. The output is kind of confusing, and leaves a mess of the workspace.

  /usr/local/bin/npx --no-install wrangler --version
  npm error npx canceled due to missing packages and no YES option: ["wrangler@3.72.3"]
  npm error A complete log of this run can be found in: /home/runner/.npm/_logs/2024-08-28T17_12_25_179Z-debug-0.log
  ⚠️ Wrangler not found or version is incompatible. Installing...
📥 Installing Wrangler
  /usr/local/bin/npm i wrangler@3.13.2

okay. Why did you do npm i instead of just npx wrangler@3.13.2 ? Doesn't make sense.

Then when it goes to run:

  /usr/local/bin/npx wrangler pages deploy ./_site --project-name=cldr
  ▲ [WARNING] Warning: Your working directory is a git repo and has uncommitted changes
    To silence this warning, pass in --commit-dirty=true

Well, yeah, you dirtied it, wrangler :)

Run git status
HEAD detached at pull/3989/merge
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    node_modules/
    package-lock.json
    package.json

So wrangler-action has added a node_modules, package.json and package-lock.json in my work area. And then complains that my work area is a mess.

I'm going to try a preemptive npm i -g wrangler@3.x to see if it cleans things up.

[jahands]

I agree, this is odd behavior. I'm also now realizing that if we stop running npm i wrangler, we may break users who did not add a step to their GHA workflow to separately install dependencies.

There's two things we should do here:

1. Only use npx instead of installing wrangler, causing the mess described here.
2. In v4, do a possibly breaking change where we always use npx (or equivalent) rather than installing wrangler in the local project (or alternatively install globally, but the former probably makes more sense.)