fix(create-vite): fix "too many arguments error" when using TanStack Router template with pnpm#21648
fix(create-vite): fix "too many arguments error" when using TanStack Router template with pnpm#21648Natejsx wants to merge 3 commits intovitejs:mainfrom
Conversation
|
is my changes able to be merged? |
packages/create-vite/src/index.ts
Outdated
| .replace( | ||
| /^pnpm dlx (\S+) -- /, | ||
| // `npm exec <pkg> -- <args>` uses `--` to split npm flags from package args. | ||
| // `pnpm dlx` doesn't need this separator, and keeping it can break CLIs. | ||
| 'pnpm dlx $1 ', | ||
| ) |
There was a problem hiding this comment.
Would you do this in the replace callback above?
There was a problem hiding this comment.
(you don't need to create a new PR for each changes)
There was a problem hiding this comment.
yes I can implement this in the replace callback!
There was a problem hiding this comment.
I pushed the changes you asked, and got 3 neutral, 2 skipped, and 14 successful checks
160ca28 to
4762396
Compare
|
Could we remove the |
|
Without the |
|
Ah so it seems like we need the vite/packages/create-vite/src/index.ts Line 856 in 8e360af |
When running
pnpm create vite@latestand selecting the TanStack Router variant, the generated command uses an npm-style--separator whichpnpm dlxdoes not require. Keeping the separator causes args to be interpreted as extra positional arguments, resulting in:This PR normalizes the pnpm path by removing the npm-only separator so the TanStack Router flow works correctly with pnpm.
Fixes #21618.fixes #21614pkgManager === 'pnpm', normalize the custom command string so:pnpm dlx <pkg> -- <args>becomespnpm dlx <pkg> <args>.replace(/^npm exec /, ...)flow (matching the pattern used bynpm create), per reviewer suggestion.--separator in place and trying to special-case downstream args parsing.--is npm-specific here and causes pnpm to pass arguments differently.I wasn't able to run an end-to-end reproduction of the TanStack Router flow due to TanStack/cli#364, but local checks/build pass and the fix is isolated to command normalization.
If there’s a preferred test location/approach for validating the generated command string, I’m happy to add it.