nodejs / node Goto Github PK
View Code? Open in Web Editor NEWNode.js JavaScript runtime β¨π’πβ¨
Home Page: https://nodejs.org
License: Other
Node.js JavaScript runtime β¨π’πβ¨
Home Page: https://nodejs.org
License: Other
To those here that are obsessive about avoiding merge commits please expand the contribution policy with technical details about how to land patches to (1) avoid merge commits and (2) keep a healthy git log in the process. I find the process kind of infuriating and have messed up the commit log slightly while landing the last few PRs.
The contribution policy is also lacking technical details about how committers should be keeping contributions to a single commit, ammending to insert the requested tags, and other minor details; it's a bit too hand wavy for a project that has built up an rigid set of conventions about how to git.
https://github.com/iojs/io.js#resources-for-newcomers
Is there an IRC channel for io.js?
Hello. I couldn't find any mention of why this project exists apart from node.js. Would love to get some clarification on that. Thanks.
Given compatibility with existing node, everything from node core would go into io core.
Continuing from there...
I found @chrisdickinson's discussion on primitives really interesting. I'm curious what primitives the community perceives as general, distinct, and necessary.
Getting started with any app should be as simple as curl https://somepath.to/install.sh | sh
or brew install io.js
, etc...
i currently have an issue when creating http.client()
requests from an options
object that is created from a constructor: petkaantonov/urlparser#5
https://github.com/iojs/io.js/blob/v0.12/lib/_http_client.js#L50
my solution would be options = Object.create(options || {})
or something, but i'm pretty sure someone's going to complain about performance or something...
what do you guys think?
I firmly believe it could greatly help the project if we had more people able to actively sort though issues, as well as good labels to sort them with.
Sorting issues with good** labels has helped a lot with managing issues over at express, and I'd like to bring that to core.
Core is, however, much larger, and we'd need more people who can do the sorting imo.
I understand that not everyone may be comfortable with more people with commiter permissions, but the reality is git is distributed and it is easy enough to fix things if anything goes awry. I think people could also be more comfortable with a boarder community "managing" the project in this way.
I propose we use some modified / extended list of express's labels, which can be found here and here. (we have a tool that helps manage them too.)
(** What makes a good issue label? I'm not 100% sure, but I feel most in the example are pretty good.)
p.s. I have bugged GitHub about an issues management repo permissions level for a long time. I'll be writing them a detailed support email shortly.
Since the plan is to provide some level of compatibility to joyent/node, are there plans to track compatibility explicitly? Providing assurance that iojs version "X" is a drop in replacement for nodejs version "Y"? At least until that compatibility explicitly breaks.
There has been a bit of discussion in #28 about what to name the binary. This probably deserves it's own discussion.
The proposed approach
Is the plan to have the installer install an iojs binary and an alias to node?
presents some additional questions:
This is intended as a placeholder and heads-up.
In the transitional period (while io.js
is gaining acceptance, node has a huge install base, and people are sorting out which binary they are going to use), package authors will need to test against both io.js
and node. Making io.js
easy to install via tools like nvm
would ease that.
nvm maintainer @ljharb says this here ( nvm-sh/nvm#590 (comment) )
If the community starts moving in a major way towards any given fork of node, and if that fork provides the same installation methods that node does (binaries and source), then this project should be able to easily support it, and I'd intend to do so.
So that's a good goal.
I'm seeing this mainly on Windows, it's a very long test and even though it works it comes too close to the default timeout (60s). This is going to result in a lot of false negatives for the test suite when running CI.
Can we either explore ways to shorten the test time or split it into multiple subtests or perhaps extend the default timeout length?
Assigning to @indutny
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.
For 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).
How 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.
A 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
.
v8
libuv
http-parser
libuv.js
-- libuv bindings to v8require
-- the module systemstdlib.js
-- every JS module you can require()
without installing as a dependency
readable-stream
npm
node-bin
-- node's command line interfaceNote 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.
The 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.
#53 and all of the other obscure streams issues that keep coming up keep on giving me headaches. Even though I "maintain" readable-stream as an extraction of joyent/node streams I still don't have a complete handle on the inner workings of the streams code and I imagine this is the same for many core contributors. I'm willing to bet that even now, nobody understands the code better than @isaacs because it's grown so complex.
As the most obvious source of JavaScript complexity in core, I propose that we move readable-stream to iojs and make it the place to file streams issues and where the code in core is extraced from rather than the other way around. It can also have its own core team, separate but potentially overlapping with iojs TC, that cares about and understands how they work and maybe the tight integration with core can be loosened (and perhaps broken completely) over time. As a separate project we can also pursue better testing (including browserify) of the code.
Let's all make some logos!
I'll go first:
license: public domain / CC0
Some other ideas:
In the TC meeting today we came up with a vision for the first release.
First, a few assumptions we've internalized that probably need to be stated for this to make sense.
If people disagree with any of those assumptions then they certainly won't agree with anything the TC determined for the initial release.
So, first release of io.js:
Some questions still left open:
build
confident we can have enough automation in place to hit this date.iojs
binary and an alias to node
?Just wondering if SpiderMoney has been given any review recently as a replacement to V8?
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey
http://www.theregister.co.uk/2014/10/28/mozilla_claims_fastest_javascript_engine_beats_googles_v8_and/
Other than from a pure performance perspective my thinking is Mozilla's is a better fit with io.js than other corporate entities.
A colleague just pointed me to this fork saying Node v0.12
but I can't find any information about it. Would be great to know more details.
Howdy from The Changelog!
We'd love to get the core team on the show sometime soon.
I'm guessing you've heard of the show, but if not -- The Changelog is a podcast covering what's fresh and new in open source. Listen to the show here http://thechangelog.com/podcast/ or here http://5by5.tv/changelog
Looking forward to talking to y'all!
Adam, EIC
Specifically all synchronous functions should be *Sync
and all other functions should be async. Mixed usage would be deprecated, but not removed for backwards compatibility.
For example, we should deprecate crypto
functions like crypto.randomBytes(length)
in favor of crypto.randomBytesSync(length)
.
There is no request for additional functionality. PR welcomed?
Reference: nodejs/node-v0.x-archive#7030
When going through #32 I noticed a reference to the mailing list. Is there a strategy for what's going to be done here?
what's the status on domains? can we deprecate it before v1?
Actually it's very strange behaviour of require.resolve, which throws an error when package not found. Add require.find method which would return null if package not found.
The path does not resolve correctly when resolving from one drive to another drive in windows using path.resolve
Although it is a reasonably small file, the project's readme is the central core of all the project's documentation, but it still uses documentation from Node.js. Some examples:
I'd suggest that a change is made to the readme so that it has more of a belonging to iojs, even if 'proper' documentation hasn't been written yet.
In the Initial Release issue @indutny says that the API shielding the users from V8 C++ API has been rejected. This lack of a shield + @mikeal's start of that thread here where it is stated that V8 will be merged as fast as possible when V8 releases brings up a very concrete problem.
The choices come down to the following if a shield is not developed for users to use. When V8 releases backwards incompatible changes to their C++ API:
Both of which have major consequences on the community who is trying to use iojs as a platform to build things on top of. The last solution, and one that makes even more sense in the world of faster releases and semver, is to protect the users and provide a stable API they can build against. The V8 API can still be there, but now there is a safe way for developers to write binary packages.
I understand that rvagg/nan exists and is even blessed. And perhaps that is the solution that core developers are alright with accepting and consider the V8 API not part of the API that iojs presents for its users. But that decision should be made official and communicated to the community that they are playing with fire if they touch the V8 API directly.
tl;dr something is up with npm and https.
I'm attempting to compose an iojs heroku buildpack :) but I'm encountering some interesting behavior.
155 info retry will retry, error on last attempt: Error: Hostname/IP doesn't match certificate's altnames: "Host: registry.npmjs.org. is not in the cert's altnames: DNS:npmjs.orgDNS:registry.npmjs.orgDNS:www.npmjs.org"
It gets more interesting. I've done the following, /iojs/bin/npm config set registry http://registry.npmjs.org/
and then npm install
completes very quickly -- both locally and on Heroku. I've then explicitly set the registry to https
on Heroku and ran npm install
again -- no errors about Hostname/IP mismatch this time, but it takes a very long time for the installation command to complete.
Any insight or suggestions appreciated!
This sucks because I want to run the Jenkins client as a service but when I do I get 4 persistent failures:
=== release test-child-process-double-pipe ===
Path: simple/test-child-process-double-pipe
grep stdin write 18
echo exit
grep stdin write 7
Command: c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\Release\node.exe c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\test\simple\test-child-process-double-pipe.js
--- TIMEOUT ---
=== release test-child-process-exit-code ===
Path: simple/test-child-process-exit-code
Command: c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\Release\node.exe c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\test\simple\test-child-process-exit-code.js
--- TIMEOUT ---
=== release test-child-process-spawnsync ===
Path: simple/test-child-process-spawnsync
sleep started
sleep exited [ 50, 509779200 ]
assert.js:100
throw new assert.AssertionError({
^
AssertionError: sleep should not take longer or less than 1 second
at Object.<anonymous> (c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\test\simple\test-child-process-spawnsync.js:44:8)
at Module._compile (module.js:462:26)
at Object.Module._extensions..js (module.js:480:10)
at Module.load (module.js:357:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:503:10)
at startup (node.js:135:16)
at node.js:866:3
Command: c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\Release\node.exe c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\test\simple\test-child-process-spawnsync.js
=== release test-child-process-spawnsync-input ===
Path: simple/test-child-process-spawnsync-input
Command: c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\Release\node.exe c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\test\simple\test-child-process-spawnsync-input.js
--- TIMEOUT ---
Compare Jenkins running as a service to running manually from cmd.
I'm using nssm with fairly standard options, running Jenkins from a 1-line .bat file and redirecting stdout and stderr to files.
Anybody have any clues about this? The only service-related problems I'm aware of are obvious ones like permissions problems. The test-child-process-spawnsync failure is particularly interesting. The sleep 1
appears to be taking 50 seconds (look at builds 47 and 48 and you'll see the same number!)--what's the significance of 50 seconds? A longer-than-expected execution might explain all of these errors but it's still not acceptable since running Node from a service on Windows is fairly common for production deployments.
In the following testcase the _flush
callback is not being called after stream.end()
.
Simply removing the stream.write(null);
line works fine.
Is it possible to end a stream with stream.write(null)
and stream.end()
or only the latter.
If so, why does stream.write(null)
prevent stream.end()
from triggering _flush
?
var Transform = require('readable-stream/transform'),
inherits = require('util').inherits;
function MyTransform(opts){
Transform.call(this, opts);
}
inherits(MyTransform, Transform);
MyTransform.prototype._transform = function( chunk, enc, next ){
console.log('.');
next();
};
MyTransform.prototype._flush = function(){
console.log('END');
};
// ---
var stream = new MyTransform({ objectMode: true });
stream.write({ a: 'b' });
stream.write(null);
stream.end();
same behaviour on v0.11.14
and v0.10.33
ref: #89
Three tests are failing on Windows now, perhaps this is related to the openssl upgrade or perhaps something that's changed in libuv, I don't have good enough data to say yet. My guess is openssl because of the recent upgrade.
Each of these uses openssl-cli.exe s_client ...
via a spawn()
and then interacts with stdin to do some funky stuff with a local server and verifies stdout. It's as if stdin isn't being properly flushed to the client.
This is the basic pattern, extracted from test-https-foafssl:
var args = ['s_client',
'-quiet',
'-connect', '127.0.0.1:' + common.PORT,
'-cert', join(common.fixturesDir, 'foafssl.crt'),
'-key', join(common.fixturesDir, 'foafssl.key')];
var client = spawn(common.opensslCli, args)
client.stdout.on('data', function(data) {
// .. verify and clean up
});
client.stdin.write('GET /\n\n');
It just hangs and the tests end up timing out. When you do an 'inherit'
for stderr on the spawn
you can see that it initializes but doesn't react to the client.stdin.write()
at all.
Then, if you do a full 'inherit'
and skip the rest of the steps and take control of it:
var args = ['s_client',
'-quiet',
'-connect', '127.0.0.1:' + common.PORT,
'-cert', join(common.fixturesDir, 'foafssl.crt'),
'-key', join(common.fixturesDir, 'foafssl.key')];
var client = spawn(common.opensslCli, args, { stdio: 'inherit' })
return
And manually type in GET /\n\n
to the console it does what it's supposed to; connecting to the local server and printing out the response.
I've tried putting a timeout on the write, I've tried using full CRLF, nothing works and I don't know why taking the parent process stdin should be any different than simulating stdin data.
Anyone?
Something that might have popped up several times before. But it would be awesome to have all source code properly commented. Why are certain code decisions made and why not. This could benefit contribution and perhaps some minor issues that popped up in the past. Question is, is their broad support for this? What comment style should be used? Should code be stripped from comments before release to save space? Etc.
Only seen on ARMv7 and goes away when you comment out this line (which does t.unref.bind(t)
).
node: ../src/async-wrap-inl.h:245: v8::Handle<v8::Value> node::AsyncWrap::MakeCallback(uint32_t, int, v8::Handle<v8::Value>*): Assertion `cb->IsFunction()' failed.
Could this be a libuv thing perhaps?
ARMv7 machine now hooked up to the CI cluster and will run with the rest of them.
Hi guys,
Just want to confirm the status of contributions as all docs still link to the joyent contribution guidelines.
I have already jumped through those hoops but moving forward, and for others that have not, should they?
@rvagg mentioned in #3 that things are still being finalised and to expect more information this week.
Should we hold off committing to this repo till things are finalised or go forth and pull request?
I will switch to anything that gives me better debug info when these two errors happen. Please just put the domain or IP or something in the message :)
Hey guys!
So I saw the TC meeting with the goal of Jan 13th for the alpha release, and am super excited to be seeing movement with this! I was wondering what I could do, as a member of the community, to help assist with hitting that goal?
I'm a full-time node dev, with no experience in C nor C++, but could possibly help with documentation or something along those lines? With this fork officially occurring, I want to do everything in my power to make sure it takes off like it should. Fishrock123, Domenic and chrisdickinson on #io.js and #node-forward irc channels directed me to nodebug.me for triaging issues on node core, but also to open an issue here to see from you guys what can be done to assist.
Thanks for all you're doing!
Trent
EDIT: Updated in light of #28
Here is a proposal for gradually moving node.js toward the ES6 future: all async methods in the node standard library which currently take a callback and return no value would instead be extended to return a Promise
which can be used instead of the callback. (The callback would become optional, if it is not already. If you are really worried about performance for legacy code, you can return the Promise
only if no callback is supplied by the caller.)
This would eliminate the need for extensive promisify
calls in code using ES6 Promise
s (or ES7 async functions), and provide an API like that enabled by the nodify
functions in bluebird
and prfun
.
Now in node we have callback or EventEmitter model to deal with async calls by default. But in my opinion it is better if every async function returns a native Promise (from new version of V8).
It does not break backward compatibility and supports optional callback if needed.
If so we just do not need to install additional package for promises like q or bluebird except additional functionality is needed.
_EDIT 2014-12-11 by @rvagg_
Comment lifted from here so it's easier to see for newcomers to this conversation.
This was discussed at the TC meeting yesterday, see #144, the aim was to be able to provide at least some kind of statement as feedback in this issue. I don't think the issue needs to be closed and can continue to collect discussion from those who feel strongly about this topic.
The feedback from the TC about incorporating a Promises-based API in core goes something like this:
A Promises API doesnβt make sense for core right now because it's too early in the evolution of V8-based promises and their relationship to other ES* features. There is very little interest within the TC in exploring this in core in the short-term.
However, the TC is open to change as the feature specifications and implementations in ES6 and ES7 are worked out. The TC is open to experimentation and providing the most optimal API for users, which may potentially include a Promises-based API, particularly if newer features of JavaScript work most optimally in conjunction with Promises. The speed of the language specification process and V8 implementation will mostly dictate the timeline.
It should be noted that a callback API is unlikely to ever go away.
We should be introducing CI builds to the GitHub PR process to verify code integrity, tests and coverage for those contributing to the codebase.
There are plenty out there, Travis-CI, Drone, Hosted Jenkins.
Thoughts?
I think it would be nice to be able to label (and filter) PRs & issues, and to have some insight before even reviewing changes as to how they impact SemVer. There are a lot of issues and PRs that have already been submitted and there's little context to them on real or potential impact to SemVer.
I opened this in part to help to understand impact of an issue, say #66, which I assume to be major
at such time as they're actually removed.
@indutny has done great work with https://github.com/indutny/node-spdy. would love to see this added and released soon after the specs are finalized :D
To make the project more welcoming I think it'd make sense to have a gitter chat room and a badge in the README. Thoughts?
Through my attempt to contribute to Node.js that resulted in practically no attention, I realized that there are a lot of unknown but good pull requests waiting on the Node.js repository, some of them sizzling for over a year. I understand that some pull requests fly under the radar or get abandoned, but I'd estimate at least half of Node.js's 240 are stagnant.
I would suggest we look for some way to implement some of these good pull requests, but I'm not exactly sure how to approach this.
Here are some searches that reveal pull requests that may never be dealt with:
Chris has provided some of the best comments on recent issues and has been a pretty active contributor for a while. He's also just a great guy and everyone likes him :)
=== release test-crypto-stream ===
Path: simple/test-crypto-stream
assert.js:100
throw new assert.AssertionError({
^
AssertionError: false == true
at Decipheriv.end (/opt/node/test/simple/test-crypto-stream.js:74:5)
at Decipheriv.<anonymous> (/opt/node/test/common.js:241:15)
at Decipheriv.emit (events.js:131:20)
at done (_stream_transform.js:192:19)
at _stream_transform.js:133:9
at Decipheriv.Cipher._flush (crypto.js:180:5)
at Decipheriv.<anonymous> (_stream_transform.js:132:12)
at Decipheriv.g (events.js:201:16)
at Decipheriv.emit (events.js:106:17)
at prefinish (_stream_writable.js:448:12)
Command: out/Release/node /opt/node/test/simple/test-crypto-stream.js
consistent across all platforms I believe. Assigning to @indutny
I'd love to see better support for embedded/resource constrained systems in terms of a minimal core, dealing with the garbage leave in NPMs (I removed a 20MB profile trace from a popular NPM the other day), and paying attention to those of us trying to run node^d^d^d^d io.js on systems with as little as 64MB of RAM and 400Mhz MIPS CPUs (think Arduino Yun).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.