getify / es-feature-tests Goto Github PK

Hi,

First of all, great project, really appreciate your work and hope babeljs to implement it on some level so we can exclude from transpiling some of the language features which are widely supported already.

What is missing here though is that usually we need to not just know existence of a feature, but some implementation details — like is there anything is missing or are there any differences with the spec, etc. Take @kangax ECMAScript compatibility table for instance — there are several tests for each future so you can see how fully each one of them is supported on different platforms. I understand that it's an early stage of the project, so maybe you considered this already, but anyway.

I just updated from Chrome 49 to 50 and expected that the unicodeRegExp test would now pass, but it didn't. Clearing localStorage fixed it:

I'd expected that the stored results would include the user agent string (or something?) so that they could be invalidated following an update – what do you reckon?

The module tests don't make sense. They will always fail, even in environments supporting ES6 modules:

1. import/export statements are allowed only in top-level scope so new Function('export var a = 1') will always fail.
2. import/export are only allowed in modules, not scripts; in browsers JS code will be able to be loaded as a module via <script type="module" src="path.js"><script>, in Node it's not fully clear yet. In any case, those tests will need to be run in a different way then every other one.
3. For import {a} from 'b' to not fail the environment needs to first be able to resolve the module 'b'.

To sum up, the tests in their current form don't really make any sense, they will always fail for multiple reasons so they should be removed.

re: umdjs/umd@992cc0d

To test that the specified Array.prototype methods have been made available on %TypedArray%.prototyipe

The code below is informing my I have a concise method property. Messing with the whitespace next to request = makes it go away sometimes. Also, killing the foo() call makes it go away.

javascript
'use strict';

define([], function () {
_createClass(x, [{
value: function bulkShare(vm, evt) {
var y = this.ssr().map(function (item) {
return item.id;
}),
request = {
resourceIds: y.join(','),
contactId: ko.unwrap(this.a()),
contactType: ko.unwrap(this.b())
};
foo();
}
}]);

return null;

});

Should be able to pass file contents for scanning instead of file names.

ArrayMethods isn't particularly useful to me. However, an exact report of which methods passed and failed would be wonderful.

The design I think would be amazing is (using "supports" as the root report object):
supports.Array.prototype = true = all tested Array.prototype methods pass
supports.Array.prototype.fill = true = Array.prototype.fill passes
supports.Array = all tested Array methods pass
supports.Array.of = Array.of passes
… and so forth.

For everything that's an API method, this would be very clean. You could then do supports.syntax.arrowFunctions etc if there was concern about namespace overlapping. Alternatively, the above could be supports.api.Array etc.

(filed per https://twitter.com/getify/status/596773738277785600)

How about storing the user-agent and checking against this (at least more often than a couple weeks) when reading the cached data? If the browser gets updated then the user agent will change and we'll catch that.

Thanks!

Due to the use of Function(…) this library cannot be used with CSP script-src 'self';. Switching to a getter-based approach that executes the feature test once and then caches the result would solve this problem.

IE11 & Edge don't follow the ES6-mandated rule that a const/let fresh binding is created for each iteration of the for loop. The following is valid ES6 but will throw a SyntaxError:

for (const i in {a: 2, b: 3}) {
    setTimeout(function () {
        console.log(i);
    });
}

Even worse, the following will parse correctly:

for (let i in {a: 2, b: 3}) {
    setTimeout(function () {
        console.log(i);
    });
}

but will print b twice instead of a b.

https://featuretests.io/

Should be a first-level directory for testify (with a package.json) that holds the lib file(s), and can thus be required from node as require("es-feature-tests/testify").

Now that ES2016 is out, are there plans for including these feature in your browser tests?

For example, newly added tests letLoop, constLoop, and letLoopScope need to have some sort of scan test in testify, if possible.

https://github.com/getify/es-feature-tests/blob/master/lib/featuretests.js#L59

Detect a parsing failure on a file that's supposed to be a module and automatically switch to parsing it as such.

[We had a short twitter chat .. you mentioned it'd be good to have longer one.]

Both babel and traceur have two workflows: static & dynamic. Static transpiles the es6 to es5 before use, while dynamic uses in-browser transpilation.

Both modes have options to include/exclude features of the transpilers, mainly to defer to the browser if it has the given feature.

This issue is to use es-feature-tests to create the options file appropriate to the browser being used, to build the options file for babel/traceur to defer to the browser. This would primarily be useful in the dynamic workflow.

It need not be a direct part of the project/repo .. but simply to document how to convert from the es-feature-tests results to an options file which exclude options already available in the browser.

Would you be open to having ES5 features tested too? Ones that can't be polyfilled that is, like Object.defineProperty.

Judging by the use of Object.keys and foreach I believe IE8 is not supported. Or at least requires polyfills. I'm not sure about old Opera. These still need to be supported by some projects or at least produce meaningful error messages instead of just quietly crashing. FeatureTest is an external dependency so it would be good to know what to expect from it.

Some transformers are merged since babel 5.8.2 c0fd4c1f9e0b18231f585c4fa793e4cb0e01aed1

Looks like is not a good suggestion to use only one.

But for now I only have some warning messages:
[BABEL] The transformer es6.parameters.default has been renamed to es6.parameters
[BABEL] The transformer es6.parameters.rest has been renamed to es6.parameters