Windows: distFiles contain backslashes since glob v10, producing broken S3 keys downstream

[amiarSlimane]

Summary

ember-cli-deploy-build@3.0.0 builds context.distFiles with:

distFiles: glob.sync('**/*', { cwd: outputPath, nodir: true, dot: true })

and depends on glob@^10.2.6. Since the glob v9 rewrite, glob.sync returns platform-native path separators (this was a breaking change from v7/v8, which always returned /). On Windows, distFiles therefore come out as assets\app-<fingerprint>.js instead of assets/app-<fingerprint>.js.

Downstream plugins use these strings verbatim. ember-cli-deploy-s3 uploads objects under literal-backslash keys (assets\app.js — %5C in the URL), so every asset ends up unreachable at its expected assets/... URL.

Observed impact

Deploying the same commit:

• from Linux/macOS → works, objects keyed assets/...
• from Windows → site is down: index.html (uploaded at the bucket root by ember-cli-deploy-s3-index, so unaffected) references assets/..., CloudFront finds nothing there and the SPA 404-fallback serves index.html in place of every script. With ember-cli-sri this surfaces as SRI errors where every asset reports the same computed hash (the hash of index.html) — quite misleading until you notice the backslash-keyed objects in the bucket.

Root cause

glob v9+ returns \-separated paths on Windows unless the posix: true option is passed (see the "Windows" section of the glob README).

Suggested fix

Pass posix: true to both glob.sync calls in index.js (lines 24 and 58):

glob.sync('**/*', { cwd: outputPath, nodir: true, dot: true, posix: true })

This restores the pre-v9 behavior of always emitting /, which is what every consumer of distFiles expects (S3 keys, manifest entries, URLs).

Workaround

Pin glob back to v8 for this package, e.g. with yarn resolutions:

"resolutions": { "ember-cli-deploy-build/glob": "^8.1.0" }

Environment

• ember-cli-deploy-build 3.0.0 (glob resolves to 10.5.0)
• ember-cli-deploy 2.0.0, ember-cli-deploy-s3 5.x, ember-cli-deploy-s3-index 4.x
• Windows (any); Linux/macOS unaffected