On Mon, Feb 13, 2012 at 7:03 PM, Rick Waldron <[email protected]>wrote:
> > > On Feb 13, 2012, at 2:21 PM, Domenic Denicola <[email protected]> > wrote: > > >> If you do a native Assertion module, maybe it should be similar to > node's. > > > >> <http://nodejs.org/docs/latest/api/assert.html> > > > > It's worth noting that Node's assert is almost (?) identical to > CommonJS's Unit Testing spec [1]. I'm not sure which came first. > IIRC node's assert was built off the CommonJS spec and hasn't really diverged much since. > > > Regardless, I think this is the job for a body like CommonJS (as > problematic as it may be), not Ecma. > CommonJS is effectively defunct. As far as I know TC-39 is really the only group in the position to pave this cowpath (and this is an explicit goal of harmony, after all). This is certainly a well-trodden path and it only needs the tiny subset of node's assert to be useful. The problem with API surfaced defined outside of TC-39 is there's no place to put them. Your `require("assert")` could be a lot different than mine, and this is a problem. A minimal API agreed to by the committee would go a long way helping here, especially if (like Set and Map) it was given a standard, official place in the global es environment. On a related note: has anyone given any thought to what shims should do about emulating @std modules? Or is there a programmatic loader API that's easy enough to shim in? That would make this kind of cowpath-paving far more fruitful. Another related note: isn't it about time the spec say something about console? :) > I speak for myself and my colleagues when I say that we've had our fill > of including scripts _just_ for the sake of having a common testing > interface. > > Forget Date, typeof null, etc. JavaScript's biggest problem is devs that > don't test their code. > Amen.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
