From 6b619a09254a4412d08349480d11a97542562388 Mon Sep 17 00:00:00 2001 From: Dan Abramov Date: Fri, 15 Dec 2017 23:51:50 +0000 Subject: [PATCH] typo --- .../blog/2017-12-15-improving-the-repository-infrastructure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/2017-12-15-improving-the-repository-infrastructure.md b/content/blog/2017-12-15-improving-the-repository-infrastructure.md index e18dcb94..b1a9bd1b 100644 --- a/content/blog/2017-12-15-improving-the-repository-infrastructure.md +++ b/content/blog/2017-12-15-improving-the-repository-infrastructure.md @@ -235,7 +235,7 @@ To avoid situations like this, we are now simulating the npm publish by [running Our unit tests run only in the Node environment, but not in the browsers. This was an intentional decision because browser-based testing tools were flaky in our experience, and didn't catch many issues anyway. -We could get away with this because the code that touches the DOM is consolidated in a few files, and doesn't change that often. Every week, we update the Facebook.com codebase to the latest React commit on master. At Facebook, we use a set of internal [WebDriver](http://www.seleniumhq.org/projects/webdriver/) tests for critical product workflows, and these catch some regressions. React updates are first delivered to employees, so severe bugs get reported immediately before they reach two billion of users. +We could get away with this because the code that touches the DOM is consolidated in a few files, and doesn't change that often. Every week, we update the Facebook.com codebase to the latest React commit on master. At Facebook, we use a set of internal [WebDriver](http://www.seleniumhq.org/projects/webdriver/) tests for critical product workflows, and these catch some regressions. React updates are first delivered to employees, so severe bugs get reported immediately before they reach two billion users. Still, it was hard to review DOM-related changes, and occasionally we would make mistakes. In particular, it was hard to remember all the edge cases that the code had to handle, why they were added, and when it was safe to remove them. We considered adding some automatic tests that run in the browser but we didn't want to slow down the development cycle and deal with a fragile CI. Additionally, automatic tests don't always catch DOM issues. For example, an input value displayed by the browser may not match what it reports as a DOM property.