Similar issue: https://github.com/Microsoft/TypeScript/issues/3956
Are transpilers adding + core.js invalid?
Recently TypeScript's compatibility score was updated and includes + core.js. Perhaps I misunderstand, but this doesn't seem accurate.
Since core.js is a library, in theory, I could just add it to any environment as I would any shim/shiv and get a boost or a bonus for compatibility from that library.
So, if TypeScript + core.js is valid, why isn't this applied for all other environments ... ie: Chrome + core.js?
If core.js was a dependency of TypeScript or otherwise directly integrated (as opposed to a 3rd party library) then TypeScript would probably get the compatibility score automatically but as I understand it, this isn't the case.
IMO, TypeScript 1.5-alpha should be represented without core.js. If core.js would really be added, it should be the same as using flags or experimental stuff in Chrome - put the semi-transparent secondary score and note that this is "with core.js" (again, why don't all have this?).
I think this would be a more consistent approach. Please educate me if I've missed something, thanks.
- weixin_39951112 4月前点赞 评论 复制链接分享
- weixin_39588983 4月前
The comparison to "Chrome + core.js" is irrelevant. Chrome is a runtime and needs to support these things natively -- the web is not going to move forward if every browser just ships a slow Map polyfill and calls it a day.
The core principle is that all of the transpilers should be scored on equal footing in terms of having a polyfill library available at runtime. Transpilers that require you to have another script library present at runtime shouldn't earn bonus points.
Your suggestion that it matter whether or not a transpiler takes a direct dependency on core.js creates perverse incentives. If tomorrow Tracuer said "Hey guys our download is now 54 kb bigger and we've done literally nothing else, so we're going to raise our score by 20 points", that's just making the download bigger and not actually improving anyone's life (presumably anyone capable of using a JS compiler is also capable of downloading a polyfill library without help from someone else). Conversely, wouldn't Babel be better if its core.js dependency were totally optional -- at which point we would lower its score? That doesn't make sense either.
I question the relevancy of whether or not TypeScript includes core.js as part of its dependency chain. If TypeScript includes core.js in a folder somewhere in its NPM download, does that actually change TypeScript in any meaningful way? Is the developer experience actually affected by downloading 1 extra library in addition to the 20 they're probably already using anyway? Does it matter to the person downloading the webpage whether the core.js script they have to load came from the transpiler's distribution or from a bower package?点赞 评论 复制链接分享
- weixin_39574555 4月前
I feel that this new title and focus is more helpful.点赞 评论 复制链接分享
- weixin_39939601 4月前
the title, yes, but I don't think this should be closed just yet. Reopening.点赞 评论 复制链接分享
- weixin_39982933 4月前
I think that both Babel+corejs and TypeScript+corejs are misleading. Some features in ES6/7/next are getting transpiled down to ES5, some features are supported (but don't get transpiled to lower ES versions), and in addition to that, it's getting more and more important, to see, which features are NOT supported, instead of 'can be achieved' by adding shims/core-js/... - Is it possibly a better choice to split it up Babel, TypeScript and core-js into seperate rows?点赞 评论 复制链接分享
- weixin_39955829 4月前
agree 💯%点赞 评论 复制链接分享
- weixin_39939601 4月前
Agreed - the same applies to
es6-shim(where it might be nice to see "Chrome + es6-shim" and "Firefox + es6-shim" etc). Also, should "babel + core-js" even mention core-js, since it comes with babel? Should "core-js" get its own column by itself?点赞 评论 复制链接分享