Max Randolph
Max Randolph
See https://github.com/dtolstyi/node-chromium/issues/44
The code changed could probably be cleaned up but will reattempt to download in the event that a `HEAD` request to standard form of the chromium binaries returns a 404/erroneous...
If error is still present after adding `refs_heds_main-` prefix, the request will fail and throw error, as that will indicate something else is wrong.
Seems that https://www.googleapis.com/storage/v1/b/chromium-browser-snapshots/o/Mac%2F913272%2Fchrome-mac.zip?alt=media is returning a 404 so it's possibly on Google's side.
From above link, a workaround can be specifying the revision number in `.npmrc`: ``` node_chromium_revision=refs_heads_main-913272 ``` edit: this seems to fail on `windows` still but works for `osx` and `linux`
Opened a quick and dirty fix for this: https://github.com/dtolstyi/node-chromium/pull/45
PR should resolve issue on all OS
Sounds good @dtolstyi. Thanks for the reply and for looking into it. It's possibly just a temporary glitch on Google's storage api which may fix itself with time. Noticed that...
Also thanks for providing the useful utility :-)
+1 for the issue. A temporary workaround is to compile/build without aot enabled. `ng build --prod -aot=false`