node-pre-gyp as non bundled dependency

[3y3]

How I understand the main reason to bundle node-pre-gyp is a usage it on installation phase.
And what happens if it will be used in postinstall step, is this resolves problem with bundling?

    "scripts": {
        "postinstall": "node-pre-gyp install --fallback-to-build",
    },

Unfortunately I can't test this now, but maybe the answer is on the surface?

[springmeyer]

Moving to postinstall might work to avoid the chicken 'n egg problem of node-pre-gyp needing to be available at install. But install would still need to be overridden to prevent npm from detecting the binding.gyp and calling node-gyp to build. So, overall: maybe this would work but it would need a lot of testing and we'd need to figure out what would make sense to put into the install to make it do nothing.

[3y3]

But install would still need to be overridden to prevent npm from detecting the binding.gyp and calling node-gyp to build

We need to redefine npm preinstall script. proof link

[3y3]

@springmeyer , this works like a charm on my Windows machine:

  "scripts": {
    "preinstall": "rem",
    "postinstall": "node-pre-gyp install --fallback-to-build"
  }

Can you test something like this for Linux or Mac. (I'm not sure which dummy command is preferable in bash).

[rmg]

The install script is run after dependencies are installed. It is essentially a pre-postinstall, but with a default that auto-runs node-gyp.

[3y3]

@rmg , my current solution (it tested on v8-debug and v8-profiler) is:

  "scripts": {
    "preinstall": " ",
    "postinstall": "node-pre-gyp install --fallback-to-build"
  }

Can you propose something more elegant?

[rmg]

@3y3 nothing more elegant, sorry.

My point was just that you can use install instead of postinstall:

 "scripts": {
    "preinstall": " ",
    "install": "node-pre-gyp install --fallback-to-build"
  }

[springmeyer]

My point was just that you can use install instead of postinstall:

@rmg - yes, but I think @3y3's point is that approach (the current, recommended approach) also necessitates node-pre-gyp being a bundledDependency as per https://github.com/mapbox/node-pre-gyp#1-add-new-entries-to-your-packagejson. And this is what @3y3 would like to avoid. The need for being a bundled dep is because node-pre-gyp needs to be fully installed before npm tries to install the module that uses it. Otherwise you can see errors where node-pre-gyp is only partially installed and cannot run because it is missing dependencies it expects. If you already understand this, sorry maybe I am missing something. Definitely happy to have more eyes on this problem.

[3y3]

@springmeyer , I switched to @rgm solution in production and it works fine. So there is no big difference between install and postinstall in this case.

[springmeyer]

@3y3 - hmm, can you explain in more detail what your solution is? You've removed the bundling and added an empty preinstall only? Explain to me how that solves the problem exactly? I think I'm missing something.

[springmeyer]

Also, keep in mind that bundling is also needed when your app depends on more than one dependency packaged with node-pre-gyp. Otherwise if:

• node-pre-gyp is not bundled
• npm's auto-deduping decides to not install node-pre-gyp for a given dependency
• then node-pre-gyp binary will not be available on the PATH and the install will break

More details at #61 (comment)

[rmg]

@springmeyer the empty preinstall is just to suppress the default value, which is "node-gyp rebuild".

The shared dependency case is a really good point, though. I hadn't thought of that.

[3y3]

Also, keep in mind that bundling is also needed when your app depends on more than one dependency packaged with node-pre-gyp

Reasonable. How about solution from #61

"install": "node -e \"require('node-pre-gyp').install()\""

I don't say that this is a final solution, but this can be good start.
My dream is to see in readme something like this:

You can simple add node-pre-gyp to bundled dependencies or < do something other >

[springmeyer]

@3y3 that did not work when I tried it before. But it has been too long for me to remember why exactly. Reading my old comments I can see that multiple issues might have been confused. Another was that if node-pre-gyp is downloaded dynamically and shares deps those deps might also be dedupes and not available in time.

However I think it is worth revisiting all this because I agree with you that is would be great to avoid the requirement. I don't have time to test all the scenarios right now so thanks for your efforts!