Skip to content
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

Merged
merged 23 commits into from
Feb 8, 2021
Merged

TypeScript: toolchain #2043

merged 23 commits into from
Feb 8, 2021

Conversation

nl0
Copy link
Member

@nl0 nl0 commented Feb 3, 2021

Description

  • use typescript compiler
  • use ts-jest
  • ditch babel
  • rm local polyfills, use polyfill.io instead
  • ditch generators and obsolete scripts
  • Changelog entry

To backlog

  • run CI jobs in parallel (build, test, eslint, prettier)
  • use ts-node for server-side stuff and toolchain, migrate that code to ts
  • consider serving the polyfills ourselves to not depend on a service outside our control (polyfill.io)

@nl0 nl0 changed the title TypeScript TypeScript: toolchain Feb 5, 2021
@codecov-io
Copy link

codecov-io commented Feb 5, 2021

Codecov Report

Merging #2043 (917dcf9) into master (bfa8329) will decrease coverage by 2.49%.
The diff coverage is 0.00%.

Impacted file tree graph

@@            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     
Flag Coverage Δ
api-python 89.36% <ø> (ø)
catalog 12.09% <0.00%> (+4.84%) ⬆️
lambda 92.60% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
catalog/app/components/JsonEditor/State.js 41.53% <ø> (+1.95%) ⬆️
catalog/app/components/Preview/renderers/Vega.js 0.00% <ø> (ø)
catalog/app/containers/Search/Search.js 0.00% <0.00%> (ø)
catalog/app/embed/debug-harness.js 0.00% <0.00%> (ø)
catalog/app/embed/index.js 0.00% <0.00%> (ø)
catalog/app/constants/style.js 73.68% <0.00%> (-7.57%) ⬇️
catalog/app/embed/Dir.js 0.00% <0.00%> (ø)
catalog/app/utils/SVG.js 0.00% <0.00%> (ø)
catalog/app/embed/File.js 0.00% <0.00%> (ø)
catalog/app/utils/Data.js 0.00% <0.00%> (ø)
... and 326 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bfa8329...917dcf9. Read the comment docs.

@nl0 nl0 requested a review from fiskus February 5, 2021 16:36
@nl0
Copy link
Member Author

nl0 commented Feb 5, 2021

@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>
Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member

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.

Copy link
Member Author

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

catalog/internals/webpack/webpack.prod.js Show resolved Hide resolved
@nl0 nl0 marked this pull request as ready for review February 6, 2021 10:05
@nl0 nl0 requested a review from fiskus February 6, 2021 10:06
@nl0
Copy link
Member Author

nl0 commented Feb 6, 2021

btw entry point bundles got ~15% smaller (from ~1.6MB to ~1.35MB)

@nl0 nl0 merged commit 41466c8 into master Feb 8, 2021
@nl0 nl0 deleted the ts branch February 8, 2021 05:12
@fiskus fiskus mentioned this pull request Jun 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants