Reading/Web/Projects/Invest in the MobileFrontend & MinervaNeue frontend architecture/Progress

The purpose of this page is to measure progress of the Invest in the MobileFrontend & MinervaNeue frontend architecture project.

Goal: Automate asset bundling (completed) ✅
Progress can be measured by looking at the amount of files and lines of code migrated to the src/ folder.

Outcomes
At the start of the project, MobileFrontend had 86 JavaScript files. This was reduced to 19 files built via Webpack from 101 source files (files inside src/ folder). The increase in source files reflects the teams ability to embrace Webpack and separate code responsibilities more effortlessly.

44 QUnit tests were updated so that the could be run from the command line. This allowed us for the first time to see code coverage of the entire MobileFrontend extension. 15 new files were added thanks to refactorings and improvements to test coverage.

At the start of the project (commit d518689) there were 57 ResourceLoader modules insiding MobileFrontend. 24 ResourceLoader modules were removed in the project leaving 34. This is important as it reduces overhead in the startup module. Similar changes are planned in Minerva and various other opportunities exist in MobileFrontend.

Goal: Speed up unit test execution and install code coverage ✅
Progress in speeding up unit testing can be measured by looking at the amount of files migrated to the src/ folder, like in the previous sub-project (automatic bundling), and the amount of test files moved or left from tests/qunit to tests/node-qunit.

Currently, we have low test coverage and are unable to accurately measure test coverage. Test coverage is measured using nyc as files are migrated to node-qunit and we aim for ~75% coverage.

The following table details progress in this area. Bold highlights total coverage (100%).

Outcomes
During the webpack porting project, we increased code coverage in a few mobile.startup modules. Despite this small effort, upon completing the Webpack migration code coverage was around the 53% mark, specifically:


 * 53.13% of our statements were covered
 * 46.84% of all branches were covered
 * 53.67% of all functions were covered
 * 53.13% of all lines were covered

Given code coverage was purposely increased slightly during this migration, the initial code coverage was likely much less, if we ignore file size and take the average % of all the columns in the table above, the average file featured code coverage with the following characteristics:


 * 50.38% of all our statements were covered
 * 39.2% of all branches were covered
 * 45.2% of all functions were covered
 * 49.4% of all our lines were covered

Most alarmingly of all, 45 of the 81 files had 0% coverage.

By the end of January 2019, we were able to enforce coverage in the repository. meaning that code coverage could only get better.

Goal: Increasing code coverage
After speeding up unit test execution and adding test coverage monitoring, it became a lot easier to track progress in this area. Given our goal is code coverage, progress can be monitored as we work towards 100%.

Refactoring responsibilities / separating concerns
The number of files in src is expected to grow while the number of files in resources is expected to decline as we make components more reusable, thus reducing the need for templates and CSS files in the latter and separate concerns in the former.

Removing inheritance
When both columns are equal numbers the goal of removing inheritance can be considered achieved. We hope the number of classes extending View will go up as we move away from large multi-concerned components to dumb components.

All: Impact on bytes shipped
It's hard to measure this as during the MobileFrontend refactor project several new projects were simultaneously worked on and shipped - including Page Issues.

At the start of the project, in August 1st we shipped 175kb of JavaScript.

https://grafana.wikimedia.org/dashboard/db/mobile-2g?panelId=69&fullscreen&edit&orgId=1&from=now-1y&to=now&tab=time%20range

On 23rd January 2019 as we begin wrapping up the work we find JS for the same page to be 170.3kb. Of course during this time, features have been added and code has changed outside MobileFrontend so it's difficult to say how much of this is due to our work.

All: Impact on errors
See Reading/Web/Notable incidents for errors that occurred during the lifespan of the project.

Most errors were unrelated to the webpack work but caught because of it. This metric will become more important as we switch our focus to code refactoring and improving unit test coverage.