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.

Automate asset bundling
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. 23 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.

Speed up unit test execution and increase 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.

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.

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.