René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Splitting node in to more projects","articleBody":"I'm going to coalesce as much as I can remember of dozens of conversations I've had with people over the last year in to an actual proposal.\n\nFor some time `node` has been getting separated in to difference projects which then become dependencies of node itself in some way. These range from `libuv` to `readable-stream` (which is just `stream` in core).\n\nHow and when a module gets broken out in to its own project has been seemingly random, although a more accurate description might be \"whenever the opportunity arrived,\" like a module rewrite.\n\nA specific \"version of node\" **must** be a static collection of these dependencies, as has been the case for the history of node, suggesting that we change this would be crazy. Below I will describe this proposal as a collection of projects (some existing and some yet to be produced) which would be locked to a specific version of each project in order to produce a single version of `node`.\n- `v8`\n- `libuv`\n- `http-parser`\n- `libuv.js` -- libuv bindings to v8\n- `require` -- the module system\n- `stdlib.js` -- every JS module you can `require()` without installing as a dependency\n  - within stdlib.js a specific released version would also have, as dependencies, many other modules like `readable-stream`\n- `npm`\n- `node-bin` -- node's command line interface\n\nNote that there is no abstract C/C++ interface on top of v8's API. Native modules would still be built using a combination of `nan` (which has the advantage of being able to stretch multiple v8/node version combinations) and direct v8 bindings, as is the case today.\n\nThe biggest benefits I see with this approach are reuse and ease of contributions. I think we would see some very interesting experiments with libuv.js. I also think that the community in userland that has had a hard time getting input in to node core would have an easier time directing that feedback towards a `stdlib.js` or `require` project which is entirely JS.\n### Concerns with this approach\n- Additional coordination cost between dependencies. \n  - How well is this handled today with libuv?\n- Additional administrative overhead, maybe.\n- Increased difficulty of making performance related improvements traversing several dependencies.\n","author":{"url":"https://github.com/mikeal","@type":"Person","name":"mikeal"},"datePublished":"2014-11-28T21:09:58.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":19},"url":"https://github.com/9/node/issues/9"}