Supporting feature tests directly

Kyle Simpson getify at gmail.com
Wed Mar 25 21:17:26 UTC 2015


> It's not that it's imperfect. It's that it's useless in the real world.

It's clear it's useless to you. It's not clear that it's useless to everyone. In fact, I for one definitely find it useful. No sense in continuing to argue over subjective opinion.


> We can already do shallow testing of APIs. Reflect.support doesn't help there, and in some ways (that I've outlined before) it is a regression.
> 
> ```
> if (!Array.prototype.includes) { ... }
> if (!Reflect.supports("Array.prototype.includes")) { ... }
> ```

As I've repeatedly said, this proposed feature is not for those sorts of tests. It's for all the syntax tests that require `try..catch` + `Function` / `eval`. Please (re)read the rest of the thread.


> You also wouldn't do testing of syntax support at runtime

I already do. I fully intend to keep doing so.


> as you would effectively be duplicating the code.

Nope, not duplicating code. Maintaining code in original ES6+ authored form as well as transpiled form. They're both files that can be loaded by a browser. So my intent is to decide at runtime which one is appropriate, and only load one or the other.


> ...send down a file that tests for support and then sends it back to the server

Yep, absolutely. Bootstrapping.


> and then build the appropriate assets for that browser?

Of course not. It picks one of two already existing files.



More information about the es-discuss mailing list