fix(c3): ensure shell scripts work on Windows

[petebacondarwin]

Our use of shell-quote was causing problems on Windows where it was escaping character (such as @) by placing a backslash in front. This made Windows think that such path arguments, were at the root.

For example, npm install -D @cloudflare/workers-types was being converted to npm install -D \@cloudflare/workers-types, which resulted in errors like:

npm ERR! enoent ENOENT: no such file or directory, open 'D:\@cloudflare\workers-types\package.json'

Now we just rely directly on the Node.js spawn API to avoid any shell quoting concerns. This has resulted in a slightly less streamlined experience for people writing C3 plugins, but has the benefit that the developer doesn't have to worry about quoting spawn arguments.

Fixes #4282
Fixes #4425
Fixes #4342

Author has addressed the following:

• Tests
  • Included
  • Not necessary because:
• Changeset (Changeset guidelines)
  • Included
  • Not necessary because:
• Associated docs
  • Issue(s)/PR(s):
  • Not necessary because: it is a bug fix with no changes to usage.

[changeset-bot]

🦋 Changeset detected

Latest commit: c06c331

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
create-cloudflare	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

A wrangler prerelease is available for testing. You can install this latest build in your project with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/6982999562/npm-package-wrangler-4445

You can reference the automatically updated head of this PR with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/6982999562/npm-package-wrangler-4445

Or you can use npx with this latest build directly:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/6982999562/npm-package-wrangler-4445 dev path/to/script.js

Additional artifacts:

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/6982999562/npm-package-miniflare-4445

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/6982999562/npm-package-cloudflare-pages-shared-4445

Note that these links will no longer work once the GitHub Actions artifact expires.

---

wrangler@3.17.1 includes the following runtime dependencies:

Package	Constraint	Resolved
miniflare	workspace:*	3.20231030.1
workerd	1.20231030.0	1.20231030.0
workerd --version	1.20231030.0	2023-10-30

|

Please ensure constraints are pinned, and miniflare/workerd minor versions match.

[codecov]

Codecov Report

Merging #4445 (c06c331) into main (61ec986) will increase coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4445      +/-   ##
==========================================
+ Coverage   75.44%   75.45%   +0.01%     
==========================================
  Files         240      240              
  Lines       12851    12851              
  Branches     3309     3309              
==========================================
+ Hits         9695     9697       +2     
+ Misses       3156     3154       -2     

see 5 files with indirect coverage changes

[dario-piotrowicz]

@RamIdeas pinging you since you've introduces the use of shell-quote generally I think 🙂

[RamIdeas]

I don't think this is the best solution for the issue.

Enforcing the use of argv-style arrays across the codebase is a DX decision and subjective, so I'm not commenting on this specifically. Notably this only considers commands/args authored within the codebase.

So even if we enforce argv-style arrays, there are still encoding issues when accepting command strings as env vars (still end up ssplitting them by space) or stringifying the arrays for printing the commands to the terminal (still end up joining them by space)

We could (a) still use shell-quote in those few cases (i.e. much less use of the lib) or (b) we could account for the @ in shell-quote and workaround the bug (and any other bugs that arise from use of the lib) and use the lib everywhere as it currently is while keeping our DX around command strings – I would favour (b)