Performing any code change without tests is risky, but changes where you're touching entire files or the entirety of the codebase are especially risky. If we hadn't had good test coverage, we would have added that before continuing with the migration. The goal of the migration was to complete it without any Puppeteer users even realising that we'd migrated, and the tests were a vital part of that strategy. This meant we could be confident that we weren't breaking code as we migrated, but also that we weren't introducing changes to our API. We were also fortunate that Puppeteer has a robust set of unit tests in place covering all of its functionality. Puppeteer has a lot of users and a broken release would cause problems for lots of them, so it was vital that we kept the risk of breaking changes to a minimum.
If anything goes wrong with one of the steps you can easily revert it. This keeps the overhead of the migration down-you're working only on a small part of the code at anyone time-and keeps the risk down, too. When planning how to migrate we wanted to be able to make progress in small steps. It therefore made perfect sense to look at migrating Puppeteer's codebase to TypeScript, too. You can find out more about that migration in our talk at Chrome Dev Summit 2020. We're big fans of TypeScript on the DevTools team-so much so that new code in DevTools is being authored in it and we're in the middle of a big migration of the entire codebase to being type-checked by TypeScript. Interested in helping improve DevTools? Sign up to participate in Google User Research here.
0 kommentar(er)
