Type safety initiatives for LINE Securities front-end

Ryota Suzuki
LINE Front-end Team Front end Engineer
https://linedevday.linecorp.com/2020/ja/sessions/5101
https://linedevday.linecorp.com/2020/en/sessions/5101

Transcript

2. About Speaker Ryota Suzuki a.k.a. @uhyo_ › Front-end engineer working on LINE Securities (LINE証券) › TypeScript Lover › Lots of TypeScript articles on Qiita and blog › Several contributions to TypeScript › Also writing a TypeScript book! Twitter: @uhyo_ GitHub: @uhyo Qiita: @uhyo Blog: https://blog.uhy.ooo/
4. Development of LINE Securities › TypeScript + React › 150,000+ LoC of TypeScript › 10+ front-end engineers working on the same project
5. Our MUSTs and Type Safety We MUST keep the service up We MUST develop fast We MUST write sustainable code
6. Our MUSTs and Type Safety Types help reduce bugs Types accelerate our development Types contribute to code design
7. Agenda › XLT: Types for i18n Utils › A Custom typescript-eslint Rule › Gradual adoption of noImplicitAny
8. XLT: Types for i18n Utils
9. What is XLT? › In-house i18n system › Admin for text management and API for exporting text › XLT = Cross-Language Translation Tool
10. Our XLT Workflow › 1. Download text data from XLT system › 2. Commit data and use it › (We don’t query data at runtime; it’s not CMS. Rather, it’s for managing text separately from source code)
11. Our Use of XLT › Query text with xlt function › Supports partial application!
12. Type Safety & DX of XLT › Of course, fully type-safe! › Auto completion is there too!
13. Code Generation for XLT › We generate a large type that accepts all possible keys (including partial ones) › Runtime code is fixed TS 4.1’s template literal types might help? !
14. Code Generation is Automated!
15. Bonus: Splitting Runtime Data with Babel
16. A Custom typescript-eslint Rule
17. Background: A Common Pattern with JSX › The {cond && <Something />} pattern › Show <Something /> if cond › Show nothing if not cond (React does not render false) › Simpler than cond ? … : null
18. Actual Code with Bug › noticeTotal is a number | undefined › What if noticeTotal is 0?
19. Actual Code with Bug
20. Actual Code with Bug
21. Summary of the Problem › 0 && … is evaluated to 0 › React renders 0 ! › In general, number && element is very bug-prone › We want to forbid this pattern
22. Our Solution: Custom typescript-eslint Rule @linecorp/jsx-no-number-andand (sorry, not OSS!)
23. Making a typescript-eslint Rule › Get a TypeChecker instance from custom parser › This provides us type information of expressions
24. Making a typescript-eslint Rule › Query && expressions at JSX child positions › Get the type of the left operand › If number is included, emit a lint error
25. Gradual Adoption of noImplicitAny
26. What is noImplicitAny? › Compiler option to forbid parameters without type annotation › Comes with other stricter checks › Without this option, these parameters get the any type! !
27. Let’s Enable noImplicitAny › Advice from me: always enable noImplicitAny when you start a new project › tsc --init already does so!
28. The any Nightmare › The any type propagates ! › Disaster to type safety › The any type disables nearly all compile errors ☠
29. The Problem › We did not have time to solve this all at once › QA would be impratically high-cost › Major part of our codebase did not enable noImplicitAny !
30. Why We didn’t? › Our project used TypeScript from start › But a lot of code was copied from JavaScript project › We didn’t know TypeScript very well, so just chose the easiest way to proceed with it !
31. 0 100 200 300 400 500 600 0 20000 40000 60000 80000 100000 120000 140000 160000 2018/07 2018/11 2019/03 2019/07 2019/11 2020/03 2020/07 noImplicitAny errors TypeScript LoC TypeScript LoC Potential noImplicitAny errors The Result
32. 0 100 200 300 400 500 600 0 20000 40000 60000 80000 100000 120000 140000 160000 2018/07 2018/11 2019/03 2019/07 2019/11 2020/03 2020/07 noImplicitAny errors TypeScript LoC TypeScript LoC Potential noImplicitAny errors The Result Took one year to solve nearly all errors Without any action, number of potential noImplicitAny errors kept growing
33. 0 100 200 300 400 500 600 0 20000 40000 60000 80000 100000 120000 140000 160000 2018/07 2018/11 2019/03 2019/07 2019/11 2020/03 2020/07 noImplicitAny errors TypeScript LoC TypeScript LoC Potential noImplicitAny errors The Result Gradual adoption Short-term attack
34. Our Long-Term Adoption Strategy › No new noImplicitAny errors! › Existing files occasionally get fixed › Disallow noImplicitAny errors in files that have diff (similar to what reviewdog does)
35. Outcome of the New Strategy › Growth of our TypeScript skill (recently CI rarely fails with new noImplicitAny error) › Development schedule is not affected › Of course, safer code (the any type is super unsafe!)
36. Review Carefully › Bad type definitions could fix noImplicitAny errors ! › Review to ensure we have good type definitions
37. The Short-Term Attack › Helps succeeding noImplicitAny fixes › We recommend performing some short-term attack at first
38. How to Do Short-Term Attack › Do the best on type definition quaility › Assign TypeScript master › Fix core modules at first
39. Conclusion Let’s enhance type safety and developer experience by various means!
40. Conclusion › typescript-eslint: Enhance type safety with additional checks! › noImplicitAny: Improve code quality by gradually adopting noImplicitAny! › XLT: Generate code for better type safety & DX!