Switch to node-build #72
Switch to node-build #72neersighted wants to merge 3 commits intoasdf-vm:masterfrom neersighted:master
Conversation
|
Awesome! I'm going to test this out locally for a couple days before merging. It looks like the build is failing due to a file being missing: Any idea what's wrong with it? |
|
@Stratus3D Looks like this line just needs to be removed from the TravisCI config Line 6 in 84c111d |
This switches asdf-nodejs to use node-build as the backend. This fixes support for platforms that do not have binaries, and removes the somewhat problematic GPG verification code. Instead, we rely on the hand-curated list of definitions that are maintained at the node-build repo. This also makes listing possible versions of node much faster, and introduces support for io.js (if anyone still needs it, I suppose) and other forks.
|
I've rebased this so it can be considered again. I still strongly recommend node-build over using the official binaries as building from source is more compatible and standard with most other version managers. |
|
@neersighted Thanks for taking the time to rebase this PR. Right now I'm a little hesitant to merge this as it doesn't look like node-build is widely used. I like the idea, but I'd rather not merge until there is more support around node-build. If node-build isn't widely used, we may up having to maintain it as well, and that lessens the benefit of removing this logic from asdf-nodejs. What do you think? |
10 similar comments
|
@neersighted Thanks for taking the time to rebase this PR. Right now I'm a little hesitant to merge this as it doesn't look like node-build is widely used. I like the idea, but I'd rather not merge until there is more support around node-build. If node-build isn't widely used, we may up having to maintain it as well, and that lessens the benefit of removing this logic from asdf-nodejs. What do you think? |
|
@neersighted Thanks for taking the time to rebase this PR. Right now I'm a little hesitant to merge this as it doesn't look like node-build is widely used. I like the idea, but I'd rather not merge until there is more support around node-build. If node-build isn't widely used, we may up having to maintain it as well, and that lessens the benefit of removing this logic from asdf-nodejs. What do you think? |
|
@neersighted Thanks for taking the time to rebase this PR. Right now I'm a little hesitant to merge this as it doesn't look like node-build is widely used. I like the idea, but I'd rather not merge until there is more support around node-build. If node-build isn't widely used, we may up having to maintain it as well, and that lessens the benefit of removing this logic from asdf-nodejs. What do you think? |
|
@neersighted Thanks for taking the time to rebase this PR. Right now I'm a little hesitant to merge this as it doesn't look like node-build is widely used. I like the idea, but I'd rather not merge until there is more support around node-build. If node-build isn't widely used, we may up having to maintain it as well, and that lessens the benefit of removing this logic from asdf-nodejs. What do you think? |
|
@neersighted Thanks for taking the time to rebase this PR. Right now I'm a little hesitant to merge this as it doesn't look like node-build is widely used. I like the idea, but I'd rather not merge until there is more support around node-build. If node-build isn't widely used, we may up having to maintain it as well, and that lessens the benefit of removing this logic from asdf-nodejs. What do you think? |
|
@neersighted Thanks for taking the time to rebase this PR. Right now I'm a little hesitant to merge this as it doesn't look like node-build is widely used. I like the idea, but I'd rather not merge until there is more support around node-build. If node-build isn't widely used, we may up having to maintain it as well, and that lessens the benefit of removing this logic from asdf-nodejs. What do you think? |
|
@neersighted Thanks for taking the time to rebase this PR. Right now I'm a little hesitant to merge this as it doesn't look like node-build is widely used. I like the idea, but I'd rather not merge until there is more support around node-build. If node-build isn't widely used, we may up having to maintain it as well, and that lessens the benefit of removing this logic from asdf-nodejs. What do you think? |
|
@neersighted Thanks for taking the time to rebase this PR. Right now I'm a little hesitant to merge this as it doesn't look like node-build is widely used. I like the idea, but I'd rather not merge until there is more support around node-build. If node-build isn't widely used, we may up having to maintain it as well, and that lessens the benefit of removing this logic from asdf-nodejs. What do you think? |
|
@neersighted Thanks for taking the time to rebase this PR. Right now I'm a little hesitant to merge this as it doesn't look like node-build is widely used. I like the idea, but I'd rather not merge until there is more support around node-build. If node-build isn't widely used, we may up having to maintain it as well, and that lessens the benefit of removing this logic from asdf-nodejs. What do you think? |
|
@neersighted Thanks for taking the time to rebase this PR. Right now I'm a little hesitant to merge this as it doesn't look like node-build is widely used. I like the idea, but I'd rather not merge until there is more support around node-build. If node-build isn't widely used, we may up having to maintain it as well, and that lessens the benefit of removing this logic from asdf-nodejs. What do you think? |
|
https://github.com/nodenv/node-build was an underlying component of https://github.com/nodenv/nodenv, which is far less used (and possibly unmaintained?) than the two leading Node.js version managers (https://github.com/creationix/nvm and https://github.com/tj/n), but I don't know if either of those have abstracted out support for building from Node.js versions from source. Regardless, updating the GPG keyring and quirks around installing/building Node.js version have been a significant pain point for migrating from other version managers to asdf, and it would be nice to delegate this responsibility to a project with more active support, while retaining the convenience of specifying and installing all exact versions of all languages via asdf. |
|
Sorry all for the lack of replies, it looks like this issue got filtered to junk mail thanks to the duplicate messages. node-build is not an especially active project, but it is actively maintained and tested across many platforms. It works well, and thus it is not any more active than it needs to be. I don't currently use asdf, but I think that switching to node-build represents a major improvement; it is significantly more ergonomic than dealing with a GPG keyring, and provides integrity guarantees through hashes in the upstream repo. You do have to trust node-build upstream, but you have to similarly trust that the I can fix the conflicts in this branch if there is interest, but I can't really test myself as I've switched back to |
|
Just wanted to point out that both |
|
I just recently installed asdf, and this is definitely a big obstacle to switching to it. For all the conveniences that asdf provides the adoption path is quite heavy with extra installations. |
|
It may be worth revisiting this. Ultimately this project is in need of more maintainers than anything else. As I don't use Node.JS on a daily basis I'm not the best person to make decisions like this. |
5 participants
This switches asdf-nodejs to use node-build as the backend. This fixes support for platforms that do not have binaries, and removes the somewhat problematic GPG verification code.
Instead, we rely on the hand-curated list of definitions that are maintained at the node-build repo. This also makes listing possible versions of node much faster, and introduces support for io.js (if anyone still needs it, I suppose) and other forks.