When Old Meets
New: Codebases
Ursula Sarracini
Ƀ Developer
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
Firefox is old
Web moves fast
1. Technical & Testing
• 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
• 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
dispatch actions
dispatch actions
receive actions
receive actions
• 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
• 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
2. Source Control & Issue Tracking
• 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 ->
• 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
3. Human & Cultural
• 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
• 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
• 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
Know when to make
the right compromises
Be open about the changes
the product is making to the
legacy code
Don’t be afraid to introduce
new tech & modernize the
old code
Thank you!
Questions?
Ƀ Ursula Sarracini
ursulasarracini
github.com/sarracini
ursula@mozilla.com
ursulasarracini.com/old-meets-new.html

Ursula Sarracini - When Old Meets New: Codebases

  • 1.
    When Old Meets New:Codebases Ursula Sarracini Ƀ Developer
  • 6.
    Firefox codebase Ourweb 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.
  • 8.
  • 9.
    • Firefox hasmany 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 has2 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.
  • 12.
    • Karma (testrunner) + 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 testsare (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 wantedto 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 wantedto 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’twant 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 takes8 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 ofdevelopers 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 tomake the right compromises
  • 22.
    Be open aboutthe changes the product is making to the legacy code
  • 23.
    Don’t be afraidto introduce new tech & modernize the old code
  • 24.
    Thank you! Questions? Ƀ UrsulaSarracini ursulasarracini github.com/sarracini ursula@mozilla.com ursulasarracini.com/old-meets-new.html