Presented at FrontConf 2017 in Munich by Ursula Sarracini When your codebase has 13 million lines of code, is written in C++/XUL, and dates back to 1998, it may seem like an impossible task to write a modern web app using technologies like React, and tools like Github, while still managing a graceful integration with the existing codebase. Developing new functionality in a legacy codebase which wasn’t originally built for the modern web can introduce a bunch of new and exciting challenges. This talk will categorize the problems of when old code meets new code in four ways: testing challenges, source control and issue tracking challenges, human and cultural challenges, and technical challenges. At Mozilla, I’m working on a major feature which was developed independently from the rest of the Firefox codebase, and has since been tightly integrated into the rest of the source tree. Along the way we have faced challenges in each of the categories. I will identify some of the pitfalls that developers can run into when trying to merge old and new codebases, and will provide practical advice in avoiding these problems down the road.

1. When Old Meets
New: Codebases
Ursula Sarracini
Ƀ Developer

6. Firefox codebase Our web app
XUL + HTML + CSS
Mercurial
Bugzilla
C++ JSMIDL
React + Redux + Sass
ES6 + commonJS
npm + babel + webpack
git
Github
8 week release 2 week milestone

7. Firefox is old
Web moves fast

8. 1. Technical & Testing

9. • Firefox has many ways to import modules
• But no way to import the same module in two different contexts
• Copy code? Write a new module loader?
• Babel to convert JSM to commonJS + webpack so we can import
them in both contexts
• Keep in mind: be ready for a mix of architectural patterns
Shared code

10. • Firefox has 2 contexts: parent & child
• Architect app using async message passing, a common store
between processes
• Firefox message manager to send messages between process
boundaries (IPC)
• Our own action dispatcher to attach Redux with the Firefox
message manager
• Wrap existing code in new code to make it work
Multi-process Javascript

11. dispatch actions
dispatch actions
receive actions
receive actions

12. • Karma (test runner) + Mocha (framework) + Chai (assertions)
• Does not exist in Firefox - they use a very old framework called
Mochitests
• Writing tests internally isn’t enough - fix the existing tests in
Firefox
• Spent a lot more time than expected fixing existing tests
• Lesson: leave plenty of time for fixing old tests
Testing Frameworks

13. • Unit tests are (obviously) very important for your app
• External dependencies in legacy codebase, affect the unit tests
• Mock out the external APIs that wouldn’t be available in the
context of our unit tests
• Wrote utility that allows you to override properties on the global
object
Mocking

14. 2. Source Control & Issue Tracking

15. • We wanted to use git because
• modern
• easy
• hg is hard
• need special review privileges to do reviews in Firefox
• Can’t use git in Firefox’s codebase
• Our flow:
git VS hg
write git patch in our repo ->
push to Firefox
periodically node script copies over files to Firefox repo ->
use hg to write a patch ->

16. • We wanted to use Github because
• modern and widely adapted
• easy to file tickets
• easy for reviews and collaboration
• Firefox uses Bugzilla to track bugs
• Go through the bugs people file on Bugzilla and mirror to Github
• Extra step in our triage
• Important not to forget the way people are the most comfortable
filing issues
Github vs Bugzilla

17. 3. Human & Cultural

18. • People didn’t want bundles in the Firefox tree - but we needed
React + Redux to exist in the repo
• Had to commit the files to the tree (not ideal, but a compromise)
• We had to write more JSMs to fit Firefox code style
• Our app wanted to be modular - lots of small independent
modules but….
• Firefox gives lots of overhead to loading modules so we had to
compromise
Bundles.js

19. • Firefox takes 8 weeks to ship an update
• On our team we have 2 week milestones
• Lots of A/B tests, style updates, bug fixes, feature updates
• Can’t afford to wait 8 weeks until people see updates
• Compromise: Ship as an add-on to the browser and get a
different release cycle
Release schedule

20. • Lots of developers are set in their ways about the Firefox code
• Change our strategy - be less isolated - write code that integrates
with the existing code
• Join meetings, talk to engineers so they know what’s coming, know
who to talk to about the legacy code
• Lots of conversations about data collection
Communication

21. Know when to make
the right compromises

22. Be open about the changes
the product is making to the
legacy code

23. Don’t be afraid to introduce
new tech & modernize the
old code

24. Thank you!
Questions?
Ƀ Ursula Sarracini
ursulasarracini
github.com/sarracini
ursula@mozilla.com
ursulasarracini.com/old-meets-new.html