Support npm run build for Wasp Studio on Windows

[nodtem66]

This is an issue for the PR #3020

Describe the bug

Cannot build Wasp studio on Windows due to the Unix commands in package.json

To Reproduce
Steps to reproduce the behavior:

• Install NodeJS
• Clone commit bba407d
• Change directory to ./waspc/packages/studio/
• Install dependencies

npm ci

• Run build

npm run build

• The console will show the error:

> wasp-studio-server@1.0.0 build
> npm run build:client && rm -rf dist && tsc && cp -r ./public ./dist/public

> wasp-studio-server@1.0.0 build:client
> npm --prefix ./client install && npm --prefix ./client run copy

> wasp-studio-client@0.0.0 copy
> npm run build && cp -r ./dist/* ../public

> wasp-studio-client@0.0.0 build
> tsc && vite build

vite v4.5.3 building for production...
Browserslist: caniuse-lite is outdated. Please run:
  npx update-browserslist-db@latest
  Why you should do it regularly: https://github.com/browserslist/update-db#readme
✓ 1057 modules transformed.
dist/index.html                     0.40 kB │ gzip:   0.27 kB
dist/assets/index-17ce6ed4.css    157.34 kB │ gzip:  18.98 kB
dist/assets/index-62a9d21a.js     496.83 kB │ gzip: 162.59 kB
dist/assets/Flow-b5112d3d.js    1,373.26 kB │ gzip: 421.00 kB

(!) Some chunks are larger than 500 kBs after minification. Consider:
- Using dynamic import() to code-split the application
- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.
✓ built in 13.36s

'cp' is not recognized as an internal or external command,
operable program or batch file.

Problem

cp -r and rm -rf are not valid commands on Windows

Environment:

• OS: Windows 11 (Build 10.0.26100)
• Node v22.14.0
• NPM 11.4.2
• Powershell 5.1.26100.4768
• CMD Version 10.0.26100.4770

PS. I've already fixed this issue

[onestardao]

looks like part of this is just unix shell commands not being compatible on windows, but that final heap crash message is a bit more interesting.

we’ve seen similar memory failures when chunk sizes in the build process get semantically overloaded — meaning, even if a single file isn’t huge, its structure or dynamic imports create large logical bundles that exceed the engine’s tolerance. sometimes this isn’t caught early because the bundler doesn’t report semantic weight, just raw file size.

you might already have patched the surface issues, but if you see this kind of heap failure again, it could point to an underlying collapse in build logic or module chunking. we’ve handled a few of these before and had to implement semantic-aware chunk guards to keep things stable. happy to share if useful.

[nodtem66]

Hi @onestardao

Indeed, I've fixed the surface issues around the unix shell commands and there are still some problem regarding the Wasp studio.
If you can reproduce this problem on Linux, I suggest opening a new issue for Wasp studio. I know it's still in experimental development, so your patch would be really useful.

[onestardao]

thanks for the thoughtful follow-up — sounds like you’re already in that rare state where folks debug not what’s missing, but why something gets misrouted inside the stack.

if helpful, we documented this failure mode in Problem Map 1.0 – No.4: Improper Semantic Boundary, which weirdly shows up even in non-AI toolchains when internal chunk logic silently fails upstream.

it’s here if you want to dig:
https://github.com/onestardao/WFGY/blob/main/ProblemMap/README.md
(also links to 2.0, which is way faster to spot the actual pain points.)

[nodtem66]

@onestardao I don't get it. Could you explain how this issue relate to Problem Map 1.0 - Np. 4: Improper?

[onestardao]

sure
happy to explain!

Problem Map 1.0 – No.4 (“Improper Semantic Boundary”) refers to a situation where chunked logic (whether in build steps, module bundling, or async resolution) silently collapses because the system thinks it preserved boundaries, but the actual logical units (like large functions, dynamic imports, or unscoped shared states) end up misaligned.

In your case, the heap crash could be a downstream symptom — the shell patch fixes the syntax-level failure, but if you later see unexpected memory churn or chunk reuse issues (especially on Linux), the root cause might be improper semantic separation in build-time logic.

We also documented a different angle in Problem Map 2.0 (semantic map version), which focuses more on when resolution trees miswire due to flattening or overload:

WFGY Problem Map 2.0

Both maps aim to catch the same class of failures, just from different points of view — feel free to dig in or ping me if you want a test patch!