-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeScript: toolchain #2043
TypeScript: toolchain #2043
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2043 +/- ##
==========================================
- Coverage 46.74% 44.24% -2.50%
==========================================
Files 335 404 +69
Lines 16769 19399 +2630
Branches 2219 2263 +44
==========================================
+ Hits 7838 8583 +745
- Misses 8009 9770 +1761
- Partials 922 1046 +124
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
@fiskus ready for initial review, i'll write a better description soonish |
@@ -26,6 +26,7 @@ | |||
<link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet"> | |||
<!-- styles for Jupyter Notebooks --> | |||
<link href="/ipynb.css" rel="stylesheet"> | |||
<script src="https://polyfill.io/v3/polyfill.min.js?features=Intl%2Cdefault%2CResizeObserver%2CBlob%2Cfetch%2Ces2016%2Ces2017%2Ces2018%2Ces2019%2Ces2015"></script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The slow download will slow all stuff below from downloading.
I suppose that the application's javascript will be inserted below and will be downloaded after plolyfill.io.
Maybe, npm
package is safer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The slow download will slow all stuff below from downloading.
brief testing shows that polyfill.io works really fast (+ caching), and it's probably more reliable than any of our homegrown solutions would be
I suppose that the application's javascript will be inserted below and will be downloaded after plolyfill.io.
that's the point, yes, to load all the polyfills before executing the app code.
Maybe, npm package is safer?
safer how?
the main point of using polyfill.io vs polyfills included in the bundle is smaller bundle size and automatic polifylling based on user-agent.
we could run the polyfill service ourselves if we dont trust polyfill.io enough, but this would require running an extra container and i'm not sure we need that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Polyfill.io will be down one day, and will block our application. If you think, that effort to avoid this is much bigger than that risk, I'm totally fine with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you think, that effort to avoid this is much bigger than that risk
yep, i think so, tho we can backlog revisiting the polyfilling setup later
btw entry point bundles got ~15% smaller (from ~1.6MB to ~1.35MB) |
Description
To backlog