{{ message }}
Repository navigation
bring useful node modules into this organization for better maintenance #4
Description
ex. @mikeal could move request here. that's the only module i can think of right now.
ex. @mikeal could move request here. that's the only module i can think of right now.
Activity
rvagg commentedon Oct 11, 2014
Not a terrible idea, we could extend it to bring in readable-stream, string_decoder, core-util-is and other extracted-from-core libraries and have them managed primarily in their own repos and have core pull them in from there. I send people to core when they bring up issues for readable-stream but there's no good reason why there shouldn't be a group of devs who are primarily concerned about streams dedicated to managing that as a totally separate project from core as long as core's needs are served by it.
Fishrock123 commentedon Oct 11, 2014
👍
dougwilson commentedon Oct 11, 2014
I ❤ "extract-from-core modules" (aka dual-life modules).
mikeal commentedon Oct 11, 2014
what about being in this org directly correlates to "better maintenance?"
request actually has a pretty active community on the existing repo, in fact I just added another contributor today. being an org has some other strange side effects, like the fact that org owners end up being committers in every repo, which blurs the lines a bit of who should be committing to what.
conversely, @hueniverse has been taking over modules that aren't maintained and pulling them in to the hapi org where he has a well defined contribution model. that could work here, if we were to define such a contribution model, but
requestis actually a fairly poor example since it finally has a well defined governance model and a healthy and growing set of contributors.Fishrock123 commentedon Oct 11, 2014
This general sort of model has been working fairly well for us in the expressjs / pillarjs / jshttp orgs.
Fishrock123 commentedon Oct 11, 2014
I would support the
"extract-from-core modules" (aka dual-life modules).living here. (Stuff likereadable-streametc.)mikeal commentedon Oct 11, 2014
readable-streamis a great example. what about modules that basically replace core functionality like https://github.com/rvagg/nan ?Fishrock123 commentedon Oct 11, 2014
My vote is for
readable-streambecause it basically is core functionality.Is
nancore functionality?Could our native abstractions be replaced with
nan? (I'm a js guy so I have no clue lol)mikeal commentedon Oct 11, 2014
nanshould be core functionality but isn't :) I wonder what @rvagg things.Qard commentedon Oct 11, 2014
As a nan user myself, I wish something like it was actually in core. It'd
be nice to have something a little more polished. There was some efforts
for a proper C API, but it doesn't seem to have gone anywhere.
On Oct 11, 2014 2:29 PM, "Mikeal Rogers" notifications@github.com wrote:
Fishrock123 commentedon Oct 11, 2014
I was interested in that. I'm not going to bother learning C++ for bindings but I would learn C.
However I'm really in the camp that is all like "rust bindings yo". ;)
rvagg commentedon Oct 12, 2014
Not quite true, see https://github.com/tjfontaine/node-addon-layer for a usable solution here, it just hasn't got the traction that NAN has so hasn't matured as rapidly. They are separate approaches though, NAN is about compatibility and making sure you don't have to discard your old code or your knowledge of V8 internals. My ideal however is to move towards something a little more runtime-agnostic so we're not as closely pinned to V8, but that's another story!
I'd be open to moving it here if there was a real benefit to that; keeping in mind that I've effectively given away chunks of ownership to other contributors so it'd have to be a collective decision.
I'd like to wait for some dust to settle though!
Qard commentedon Oct 12, 2014
Yep, I'm aware of it. nan seemed more popular and better maintained last
time I wrote a native module though.
I agree a more runtime-agnostic approach would be great, as would having it
in core node.
On Oct 11, 2014 8:04 PM, "Rod Vagg" notifications@github.com wrote:
Fishrock123 commentedon Oct 12, 2014
What about having these things be "official" - but eventually not in core itself? Sort of what http://r.va.gg/2014/06/why-i-dont-use-nodes-core-stream-module.html talks about.
Though in that case we'd have to have a spec so things stay consistent and sane maybe.
Probably a bad idea.maybe idk.kkoopa commentedon Oct 14, 2014
I guess NAN got more traction for two reasons: Critical mass and the degree of how much the syntax changed. We created critical mass by submitting finished PRs to every project we found, I've done about 20, @rvagg has probably done about as many. This was both to test the code and approach, as well as to build critical mass.
Then comes that the syntax did not change terribly much, existing code can still be almost fully automatically ported through simple regexes. This was intentional to make it possible to port all those projects and get the code accepted.
It may not be ideal, but standard engineering doctrine says 80 % delivered now is better than 100 % never delivered. NAN will eventually become obsolete, as people want to take advantage of domains and multiple isolates and all the new things that have been introduced in v8, but that will also entail said addons dropping 0.10 support, which is probably a couple years in the future. Because v8 is a moving target, this problem cannot be resolved without completely abstracting away v8, which probably will not work too well and still will not guarantee never breaking again, as something unforeseen will come up at some point.
That being said, I agree with @rvagg, moving it here is possible, and probably beneficial in that the vast majority of native addons now use NAN. It has become a de facto standard and it will be (already is) annoying for addon writers to report bugs in Node when they first have to translate their failing code to raw Node so as not to be dismissed with the no third-party addons excuse. However, this brings us into what @Fishrock123 wrote, the often forgotten second party remains a possibility. For example, six is a semi-official compatibility package for python 2 and 3. Then there are plans of doing NAN for libuv too, which will probably be a separate project, and so on. Maybe this is indeed the best option?
ronkorving commentedon Oct 15, 2014
@kkoopa And I'm still greatful for those contributions to this day ;) (https://github.com/JustinTulloss/zeromq.node) It made a big difference to the project and its Node 0.11 and backwards support.
martinies commentedon Oct 20, 2014
Great idea! We (like many others) struggled with many modules not getting a support. Once we made a small fix but couldn't even reach to the developer to update the package on npm..