Open piranna opened 7 years ago
Interesting idea! 👍
Would the following install script work for you?
"scripts": {
"install": "prebuild-install || (npm install nan && node-gyp rebuild)"
}
This way prebuild-install
will remain lightweight and will only handle the downloading of the prebuilts.
Would the following install script work for you?
"scripts": { "install": "prebuild-install || (npm install nan && node-gyp rebuild)" }
Yes, you got the idea ;-) In fact I was thinking about doing it like this in a first time, but when you have several buildDependencies
the install line gets too long and complex, and also there's the problem that doing it that way these dependencies get unversioned and will always install the latests ones, that's not always desirable (or set them as package@version
, making the install line more long and complex...).
npm
also supports a syntax like npm install nan@^2.4.0 node-ninja@^1.0.0
which is versioned and for me not much bulkier than implementing buildDependencies
.
When I said "versioned" I mean "automatic versioned", it's said, dependencies could be check and updated using node-check-updates
and similar tools.
When I said "versioned" I mean "automatic versioned", it's said, dependencies could be check and updated using node-check-updates and similar tools.
Ooh I see, that wouldn't work.
Though one could still add them as a devDependency
and and make use of update notifications via node-check-updates
. This way one could update the install command with minimal effort.
Though one could still add them as a devDependency and and make use of update notifications via node-check-updates. This way one could update the install command with minimal effort.
Yeah, but this way you need to have them defined in two places that would get unsync.
I've giving a look at your idea of the install
script and I've created the buildDependencies module :-P It's just a simple command that look for the buildDependencies
and devDependencies
fields and exec npm install
with them, and I've give it the possiblity to define the name of the field with the list of dependencies instead of the default buildDependencies
. With that, now there's no need to add this functionality to prebuild-install
, although the module is importable so we could add it as a dependency and done it automatically too. If not, I think it would a good idea at least add a reference on the docs about it in case others are in the same situation... What do you think?
By using
prebuild-install
I've found mostly is the only one dependency I need, except when it can resolve to a prebuild image and needs to be compiled, for examplenan
and similar ones that are useless for prebuild images. I could set them asdevDependencies
, but in that case they would not be available if the prebuild is not available, so that dependencies are in a no-man-land status.For that situation, I think a solution would be a
buildDependencies
where to set the dependencies needed only when the prebuild image could not be fetch (because it's not available or due to download failure), that would be installed byprebuild-install
itself. This could be done being thatbuildDependencies
an independent field object with no relationship with the other dependencies, or it could be an array with the name of thedevDependencies
that are in fact build ones, so this way it could be integrated with current workflows and being compatible with tools likenode-check-updates
and similar ones.Thoughts?