Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
multi-stage install #5919
When the user types
I'd like to see a clear separation between building up the representation of the "real" (what's available to the app on disk) tree and building up the "ideal" (what's specified in
Good point. I think that the "read, eval, operate" sections are somewhat implicit in the algorithm above, but they should be explicit. How's this?
generate list of operations
Of course, this is only the most simple situation (install missing deps). Nothing to clobber, no shrinkwraps, etc.
The "eval stage" for a shrinkwrap install:
To "replace" a node, we do a "remove" operation followed by an "add" operation.
To "remove" a node:
So, changing a node for a shrinkwrap swap would be something like:
And then I guess after doing the "operation" list, we do the "cleanup" list, which should be things that can fail, but even if they do fail, then it doesn't bork the install, so we exit non-zero, but don't try to roll back (since the "cleanup" items will bork a rollback, and won't be attempted until after we have everything in the desired state anyway.)
This is what I've had kicking around my head for the last month or two. It's not entirely dissimilar from what you're proposing, but there are some key differences. It also probably needs another couple iterations to incorporate more of the edge cases around shrinkwrapping and deduping.
All traversals are breadth-first, unless otherwise specified.
Print out the list of what was installed (and optionally the list of what was cleaned up, as well as the current and ideal trees).
referenced this issue
Aug 15, 2014
I think this will make things much nicer. It would also be nice if programmatic users could plug into the pipeline at multiple points, similar to how browserify allows for extensibility: https://github.com/substack/node-browserify#bpipeline.
This was referenced
Sep 25, 2014
Let's say we have two packages, A and B. A depends upon B, and B depends upon A. Someone wants to contribute with A, grabs its code from github, navigate to its directory and runs
Is there any posibility to end with a tree like this?
And if it could be possible, would it be cached by require? Thanks for all the awesome work :)
EDIT: it seems that placing the A folder dropped from github inside a directory named "node_modules" solves the problem