Native Assertion module?

Dean Landolt dean at
Mon Feb 13 18:43:43 PST 2012

On Mon, Feb 13, 2012 at 7:03 PM, Rick Waldron <waldron.rick at>wrote:

> On Feb 13, 2012, at 2:21 PM, Domenic Denicola <domenic at>
> wrote:
> >> If you do a native Assertion module, maybe it should be similar to
> node's.
> >
> >> <>
> >
> > 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list