Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to fail completely via flags if the remote isn't available #40

Open
reconbot opened this issue Aug 7, 2017 · 8 comments
Open

How to fail completely via flags if the remote isn't available #40

reconbot opened this issue Aug 7, 2017 · 8 comments
Labels
discussion Discussion enhancement New feature or request

Comments

@reconbot
Copy link
Contributor

reconbot commented Aug 7, 2017

I'd like to test if the download works. With node-pre-gyp I was able to install the package like so and ensure it downloaded and not built.

npm install serialport@beta --fallback-to-build=false

I use this in CI to ensure the state of all the builds before publishing the npm package. It's also been able to catch npm bugs on different platforms. It has been very helpful.

Since my package.json install line now reads

    "install": "prebuild-install || node-gyp rebuild",

I need to convince prebuild-install to not download and not error, or convince node-gyp to not build if it gets run.

Is there a known way to achieve this?

Thanks!

@mathiask88
Copy link
Member

No, this is currently not possible. The standalone check was implemented as a little help for the module developers, so they don't have to specify --build-from-source every time they want to build their modules.

@ralphtheninja I see two options here:

  1. remove the standalone path (major)
  2. add a new argument for this case like --force-download that skips the standalone check (minor).

I am tending to 1 because prebuild-install was made to download the binary. And it should only exit if a user don't want to or a download is not possible. And for developer there are still two aliases for --build-from-source --compile and -c wich should be documented :)

@ralphtheninja
Copy link
Member

I need to convince prebuild-install to not download and not error, or convince node-gyp to not build if it gets run.

I was a bit confused by this. If I understand correctly, you want prebuild-install to download and if that fails it should fail?

How about adding prebuild-install --test instead, you could then have a pretest script that's being run when testing (or add another script and execute it explicitly in e.g. .travis.yml)

@mathiask88 What do you mean with "the standalone path"?

@ralphtheninja ralphtheninja self-assigned this Aug 7, 2017
@mathiask88
Copy link
Member

@ralphtheninja I meant this behavior.

@reconbot
Copy link
Contributor Author

reconbot commented Aug 7, 2017

I think the --test flag would need to process.exit(0) to prevent the binary from being built from node-gyp with the recommended setup.

Unless --test would be used for testing to see if it could download the package and not actually installing the binary?

I'd prefer to keep this in the install processes so I can verify that not only it downloaded but the download works.

eg

npm install --prebuild-test
node ./ # Would fail if binary isn't present 

Funny enough this works on linux, false takes any argument and fails

node-gyp rebuild --make=false

but I don't know how to pass it through npm install

@mathiask88
Copy link
Member

Oh, ok I misread. I thought you want to download the binary in your dev environment, ignore my last answer then :)

@ralphtheninja
Copy link
Member

Oh, ok I misread. I thought you want to download the binary in your dev environment, ignore my last answer then :)

This is my current understanding as well :)

@mathiask88
Copy link
Member

@reconbot Is this still a thing?

@reconbot
Copy link
Contributor Author

Yeah, unless there's been new features I don't know about. This allows me to test our build pipeline and ensure we have binaries published and useable without having to build something to test prebuild-install.

@ralphtheninja ralphtheninja removed their assignment Aug 10, 2018
@vweevers vweevers added discussion Discussion enhancement New feature or request labels Apr 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants