[TASK] Migrate to Typescript

[ghost]

Intro

MM has evolved to something much larger that an tiny browser-extension. The mm organization hosts now the browser-extension, a mobile browser, a plugin-system (kind of "browser-extensions within a browser-extension"), the "gaba" (which looks like a component model) and more.

The lead/core-developers are very busy with all those (and other) sub-projects. As a result of this, the quite important migration to typescript has fallen a bit back. The already existent so called "technical debt" (e.g. polishing existent code to have flawless technical quality) increases.

Migrating to typescript whilst having so many "moving targets" (software which is live, and in the same time under heavy development - or software which is under development, but depends-on/rewrites existent software) is not that simple.

It is a task which needs the stewardship of an experienced senior+ dev who can focus fully on this, without distractions from daily business / production. Ideally, this dev has past experience getting an overview-of/feeling-for the overall mm-codebase.

The Typescript migration is the basic step to refine the code-base further on a higher grade (e.g. abstract further, increase reuse, simplify dive-in and maintenance, "fuse" gaba/plugin into main-codebase)

Preparation

• collect MM requirements (e.g. ES6, tools used etc.)
  • see https://github.com/MetaMask/gaba as a guideline
• extract a process (lookup use-cases, experience reports, guides etc.)
• extract a sequence (in which order to convert the packages/modules)
  • result: no binding sequence, the migration-process allows for incremental migration (e.g. no single chunk migration necessary), which allows more or less to start conversion organization wide.

Process Requirements (draft)

Must

• Use Refactoring (strict, zero functional change)
• Use smaller increments/steps (Enable strictness once a package migration is finalized)
• Auto generate type-definition (.d.ts) files

Should

• Keep style/config etc. aligned with https://github.com/MetaMask/gaba (at least subset)
• Be applicable even to heavy in-development packages.
• Switch to yarn (verify if its a non-critical change)
• Leave MM Developers in Peace (daily business as usual)

Maybe

• Result 100% documented Sources
• Result in Cleaned-up Project resources (e.g. github repo of package)

Process (draft)

• (ideally) resolve open PR's / Issues of package
• make first changes whilst keeping .js files
• incrementally add types / documentation (not all at once)
• file after file switch to .ts files (not all at once)
• enable strictness once finished
• decide: merge work incrementally, or keep commits in branch and do final merge
  • this should depend on several factors (like e.g. dev-activity, dependents etc.)

Execution (draft)

Local Test

etg-sig-utils, eth-keyring-controller, eth-simple-keyring

• Applied successfully to multiple packages (minimal effort, zero functional change)
  • incrementally complete the migration of the packages

Production

• Apply the test on live project repos

• Start Migration

• pick package

  • apply process on a package
  • revise process & migration-guide
  • go to next package/module and repeat

Team

• executed by dedicated sub-team
  • 1 senior/architect dev
    • Stewardship
    • extract/introduce necessary abstractions
    • research & decide for problem solutions
    • take the blame if things go nirvana
  • 1 junior/middle dev
    • assistance, 2nd opinion (pre annoying other devs), mass coding-work,
  • any team-members who wish to migrate their owned code themselves)
    • migrate code based on the specified process/requirements
  • now and then core-devs
    • code-owners answer questions tagged in code

Duration (estimate)

Full Budget

• 3 to 6 months (end of Feb/May 2020), for the overall mm organization
  • possibly align with "go-live" dates of new products (e.g. snaps)
  • possibly align with release of existent products (e.g. extension 8.0)

Reduced Budget

(seems not applicable, as core-devs are not available and have anyways their backlogs)

• 1 to 2 months (possibly not full-time) is the minimum(!) needed involvement of the senior/architect role
  • reduction by relaying more workload to middle/senior devs.
  • overall duration would be still 3 to 6 months

Resources

• https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#names

Personal

I'm applying for the senior/architect role here. Would be productive from "day -n", as I've already started dive-in already, and have the code-base feeling from past tasks. additionally, my estimates re time-frames are usually kept.

[ghost]

@danfinlay , I've updated the issue-text as usual. Should you choose for it: it's ready for a "go", all preparations are done on my side.

[Gudahtt]

We're still working on this, but progress is now being tracked elsewhere, outside of GitHub.