compat-table
compat-table copied to clipboard
kangax
uglify-es on the compat table
is regular uglify on the compat table?
This really doesn't seem like something that belongs here.
@graingert yes, i'm aware, but we don't have that on the ES5 compat table either. Generally the compat-table has engines (browsers, platforms, etc), transpilers, and shims - uglify is none of these things.
If babel-preset-env wants to target it, I think uglify-es should provide and maintain its own list of supported features.
would be good on the compat table too, but I think it supports all of ES5, whereas uglify-es supports a subset of ES2017
I think uglify-es should provide and maintain its own list of supported
@ljharb oh yeah that would be way better, babel-preset-env could just import that at runtime.
I'm concerned it would create a slippery slope to adding any tool that parses JS to the table - eslint, for example, or any of the alternative linters and parsers out there.
I just don't think it'd be useful or relevant to most people.
a slippery slope to adding any tool that parses JS to the table
Not sure it would be that bad if there was a requirement that the package maintain it's own compat-table compatable feature definitions and hit a certain number of npm downloads.
That also presumes that "number of npm downloads" is a meaningful metric :-)
@ljharb I picked a metric out of the air. Maybe set a hard limit of 3 packages, and pick the top 3 of whatver metric chosen with compat table rules.
I'm strongly against adding it to the table as all other JS parsers, transpilers, polyfills and similar libraries. It just does not belong here. I'm also against having transpilers, shims and polyfills in the table (which are already there unfortunately).
Is data on libraries meaningful? For engines/platforms there are only two outcomes of the tests: supported and not supported. Obviously there is also behind the flag case, but it's still meaningful. For all the transpilers, polyfills, uglifiers, etc there are at least 4 outcomes: parser errors on the feature (not able to parse), transpiler supports feature if runtime supports it (transparently passes it through), transpiler polyfills feature partially* (so it runs if runtime supports some other feature), transpiler polyfills feature completely.
Does it worth the effort? Another argument is that updating data for new version of transpiler/library is just hell to manage. For platform/runtime what you need to do is just rerun test suit on new version and add data to table. For transpiler/library/polyfill it's mostly manual process of reading changelogs. You can not just run suite, because results are influenced by runtime you're using to run them. It's just hell to manage. Look for example at #919, which is open for almost a year (now it's TS 2.4 released) and nobody updates it. I tried and it's just not feasible to put effort into this.
Is it anyhow useful? If you're choosing transpiler/polyfill seeing how many ES* they support is just not feasible, same as putting all those in the same row in comparison: babel aims to transpile new ES* features and add polyfills, TypeScript adds strong typing and transpiles some ES* features, but doesn't add polyfills, Closure Compiler optimizes JS, es6-shim is just polyfills (why it is in the same row with TypeScript + core-js, which is transpiler + polyfills). There are too many questions and inconsistencies. If the only thing you want is to check if some particular feature is supported by particular library, library docs is the perfect place to do it.
If every other tool that parses JS or has some polyfills is to be added I think it should be a separate table with more states than yes/no and billion of * around the place explaining every "it sort of supports this, but ...".
Sorry for the sentiment.
- For example TypeScript supported
async/awaitsyntax by transpiling it to generators couple of versions ago. So it will work only if generators are supported by runtime.
