- identify the pain points of mobilefrontend in terms of difficulty, efficiency, and ease of building and maintaining features from their perspective
- brainstorm optimal solutions
- provide result to whomever T156259: [Spike 1hr] What technical problems do we need to fix from mobilefrontend - ENG is assigned to
Unless otherwise specified, bullet points refer to front-end code.
- More than 1000 lines of JSON configuration with order of files and dependencies. Manually specifying and reasoning about the dependencies between files is error prone and has caused us many problems.
- Unit tests take too long to run since they require a running instance of mediawiki, so each test run needs to load a page and all the resources from the server. This complicates doing test driven development because of the long feedback cycles.
- Many unit tests are integration tests.
- Tooling runs through grunt, making it slower than it should.
- Example, running eslint directly from the cli, instead of using grunt, usually takes half or even a third of the time for doing the same linting.
- There are no code coverage reports, and when we had them we were at a quite low coverage.
- Too many style sources. There's probably a lot of unused styles.
- No CSS naming convention, really hard to know what html a selector will affect to. Hard to know if changes will change styling in unexpected places
- Tooling is php based and outdated. There's more modern tooling like uglify that would shave the size of our files by a big chunk, or newer lessc compiler versions that fix bugs and add good features.
- Can't use front-end libraries from npm.
- Templates aren't pre-compiled, resulting in sending the compiler and the source to the client, and compiling it there. Mobile browsers are under-powered and shouldn't be doing any of that.
- Code complexity seems to be high and quality low (hard to quantify, here are some things to look at):
- Responsibilities are coupled (view + logic + fetching in the same place, big methods that do a lot)
- Tests are full of stubs/mocks, which indicates high coupling of the artifacts and not good design
- 1 level deep file hierarchy because of restrictions to run all tests automatically or otherwise having to manually specify all the tests files in proper order and dependencies.
- Complicated to reason about the code entry points on a given page. Resources are added from many different places, php pages, hooks, on the module definitions.
- No live UI components style guide.
- jQuery is big and heavy to parse and run. Is it really needed in the mobile site given the clients it serves? Can we improve performance by using DOM apis instead?
- Adopt tooling that...
- allows us to have real commonjs modules and let the tools bundle the files in order
- allows us to consume libraries from npm
- allows us to use tools from npm like uglify and lessc
- Generate code coverage reports, and reject patches that decrease code coverage in CI
- Migrate browser tests that depend on a mediawiki page to an isolated environment like node.js, so that they run faster and they enable red/green cycles for TDD
- Refactor qunit tests that are integration into unit tests
- Migrate away from grunt to use the tools from the command line either in npm scripts or directly in node scripts
- Identify dead styles (there are many ways to do it) and remove it
- Refactor styles to follow some sort naming convention (like suit css or bem), and avoid cascading when possible (so that it is easy to identify which styles are used where)
- Reduce code complexity by agreeing and syncing on what is code complexity and actively refactor and analyze where it is.
- Improve the code convention to how test files and source files are loaded and in which folders they need to be
- Work to define the entry points/types of pages, create real entry points, and include from them the other common sources than have to be loaded in many pages
- Create a live UI components style guide that feeds from the source, and breaks CI if it breaks. It should generate on each commit and be public in a URL for checking it, both from master and on every patch
- Don't use jQuery
And in general:
- Have strong technical direction, ownership and standards from lead engineer
- Sync engineers
- Actively plan and work on tech tasks every sprint