Installing npm package is very slow in China
I've noticed that there's a postinstall script for downloading binary file of dprint from GitHub Releases, but connecting to GitHub Releases from China is very slow, which causes installation of dprint takes very long time, even failed in some cases.
I know the network issue can't be simply solved by us, but can we come up with some workarounds?
~~I want to get canary builds as well for dprint so I'm thinking to maybe host these on a separate service like azure storage.~~
Edit: Nope. I'm going to make the install more like esbuild and only use npm.
I'm going to make the install more like esbuild and only use npm.
@dsherret so you mean just put the binary in the npm packge? :+1: for that. Install scripts are considered harmful these days and often disabled by users due to type-squatting vulnerability and just being stupid in general.
Edit: Nope. I'm going to make the install more like esbuild and only use npm.
Is there any progress on this? Or could I do it?
Not only in China but also in Europe network issues arise:
Unknown status code 503 : Egress is over the account limit.
[exec] Step #2 - "install": ? ? Resolution step
...
[exec] Step #2 - "install": ? ? dprint@npm:0.32.1 must be built because it never has been before or the last one failed
[exec] Step #2 - "install": ? ? dprint@npm:0.32.1 STDERR Error downloading dprint zip file.
[exec] Step #2 - "install": ? ? dprint@npm:0.32.1 STDERR
[exec] Step #2 - "install": ? ? dprint@npm:0.32.1 STDERR Error: Unknown status code 503 : Egress is over the account limit.
[exec] Step #2 - "install": ? ? dprint@npm:0.32.1 couldn't be built successfully (exit code 1, logs can be found here: /tmp/xfs-76119ab7/build.log)
[exec] Step #2 - "install": ? ? Completed in 18s 872ms
dprint should now support the HTTPS_PROXY environment variable when installing via npm in ~~0.34.0~~ 0.34.1 (and NO_PROXY). Maybe that helps out in this scenario?
dprint should now support the
HTTPS_PROXYenvironment variable when installing via npm in ~0.34.0~ 0.34.1 (andNO_PROXY). Maybe that helps out in this scenario?
Thanks for reaching out to us, I wasn't aware of how https proxy could help us out indeed. Am i correct to say that does require setting up a http proxy in our network (or close enough at least). I would have to check if the need is that big to do that setup just for dprint npm package.
I have currently installed dprint natively on our build images and we demand our developers to install dprint manually on their system.
Maybe an option to override the download url would help us, but not sure if someone in our team will be willing to download / upload dprint zip files to that download folder. Woulld that make sense for you? An option do override the download url?
Using proxies isn't reasonable for CI.
again
Edit: Nope. I'm going to make the install more like esbuild and only use npm.
Is there any progress on this? Or could I do it? Are you open to a PR?
@dsherret Hi, I have asked many times. I can submit a PR to update current github workflow make it work like esbuild. Do you plan to do it yourself? Or if it's ok I submit a PR?
@trim21 sure, and sorry for missing this. Would you be able to do it by using a Deno script written with Dax (https://deno.land/x/[email protected])? It could be added here: https://github.com/dprint/dprint/tree/main/.github/workflows/scripts -- then spawned in the publish step. Would that work?
Ideally, the package.json's would be generated in a temp directory then published to npm. We can use the @dprint org to prefix the packages.
I'm working on this right now.
This should be released now in 0.38.0. Let me know if it works or doesn't work for your platform.