The lack of tooling or support for tooling has been causing problems in complicated code bases like the codebase for our mobile site, so we carved out a proposal to create a bridge from our existing codebase to a more modern one using Webpack. I'll talk about what we did and why.
we essentially had to fill out paperwork to create a file" and now "adding a new file is as easy as right click new file".
- Webpack manages complicated dependency trees for us which avoids loading errors (e.g. code loading in the wrong order)
- gives us more control over public and private interfaces to community gadgets
- allows us to expose interfaces for testing
- encourages separation of logic into reusable modules (files) without any mental strain
- allows delegation of problems such as code splitting to tooling rather than the human mind
Making code easier to work with
Now that we make use of Webpack, we only have to require it via a require statement. This might seem basic stuff, but it has made a big difference.
Similarly, we've not had to worry about polluting the global namespace. Previously all our files were wrapped in an IIFE but now we've been able to remove that wrapper and also the indenting associated with it.
A familiar stack
While we didn't measure it, and it could just because we hire awesome people, we've all noticed that our new hire got up and running with our code much quicker than previous hires.
Faster unit tests
Previously, our unit tests couldn't be run cheaply on the command line in Node.js. Any npm script wanting to run them would have to boot up a browser e.g. Phantomjs and have a working MediaWiki instance. This was slow, manual and error-prone as tests from other unrelated projects could break our own tests. It was pseudo-integration testing than unit testing. Now, with a few minor changes (mock libraries that emulate "MediaWiki"), we can run these tests from the command line in headless mode using the qunit node library. We use Webpack to build a file that can be run in the old method, to avoid confusing developers in other teams who are used to running tests this way. During our refactor, 44 QUnit tests were slowly migrated to run in Node.js.
This is obviously much faster as it doesn't require a MediaWiki install and doesn't require booting up a browser. As a result, there is more motivation for engineers to write tests in the first place, in fact we've already added 15 new test files.
As we refactor with our remaining project time we aim closer to 100% test coverage, now that our tooling makes it easier to write tests and we are now able to enforce coverage in the repository via the nyc library meaning that code coverage can only get better.
More future-proof code
While we've been forced to look at the code, we've been noticing ways to improve it and prepare it for a modern future. We've been replacing calls to jQuery with calls to a wrapper for jQuery, meaning it's becoming clearer about what we use jQuery for, and when and how we might not need it. By keeping the definition of our project around problems rather than solutions, it's been easy to justify and prioritize this work.
Similarly, we've been migrating to use ES5 functions where possible instead of jQuery.
Webpack didn't solve everything
I'll re-link to the very much related post series we did last year, that does a deep dive in to this kind of workflow with Extension:Popups:
Thanks! I'm also linking to this blog post from https://medium.com/freely-sharing-the-sum-of-all-knowledge/how-we-tackled-technical-debt-at-wikipedia-d52030065e2c (which has a shout out to yourself ;-))