fix links according to new docusaurus 2

website/blog/2021-03-11-jest-27.md

@@ -21,7 +21,7 @@ Speaking of snapshots, one of the more exciting features we've shipped in recent
 And so for most of these years, we've had a [pull request](https://github.com/facebook/jest/pull/7792) in the pipeline to eliminate this restriction and allow using **Inline Snapshots without Prettier**. It has amassed well above a hundred comments, not even taking into account PRs split out from it and landed first, and even changed owner once after the initial submission by another first-time contributor, [@mmkal](https://github.com/mmkal) under the hilarious working title 'Uglier Inline Snapshots'. With the stellar rise of Prettier in recent times, this improvement is now maybe less needed than back in 2018, but still, we know that feeling of getting into a project that does not use Prettier, and suddenly not being able to use inline snapshots anymore. Nevermore!
 
 The main reason why it took us so long to land this was, somewhat surprisingly, an out of memory error on our build pipeline. It turns out that the dependencies we load for each test file to perform the parsing, snapshot insertion, and printing do incur a significant time and memory overhead.  
-So with some [tricks](https://github.com/facebook/jest/issues/9898), we've **sped up the initialization per test file** by roughly 70% compared to Jest 26. Note that you will almost certainly not see this big of a performance improvement on your project—you would need a lot of test files that each run very quickly to best notice this, and the overhead when using a [JSDOM environment](/docs/en/configuration#testenvironment-string) dwarfs any such improvement.
+So with some [tricks](https://github.com/facebook/jest/issues/9898), we've **sped up the initialization per test file** by roughly 70% compared to Jest 26. Note that you will almost certainly not see this big of a performance improvement on your project—you would need a lot of test files that each run very quickly to best notice this, and the overhead when using a [JSDOM environment](/docs/configuration#testenvironment-string) dwarfs any such improvement.
 
 In other news, the [native ESM support](https://github.com/facebook/jest/issues/9430) is progressing, but some major complexities, for instance around mocking, are still ahead of us, and we continue to observe the migration to ESM as a huge ecosystem effort, where Node and a lot of crucial tools and packages all have to rely on each other to deliver an overall compelling experience.
 
@@ -31,20 +31,20 @@ We've also merged [a PR](https://github.com/facebook/jest/pull/9351) to be able
 
 <!-- TODO pending merge https://github.com/facebook/jest/issues/9504 -->
 
-[Another PR](https://github.com/facebook/jest/issues/9504) enabled [`transform`s](/docs/en/configuration#transform-objectstring-pathtotransformer--pathtotransformer-object) to be asynchronous, a requirement to support transpilation through tools such as [esbuild](https://esbuild.github.io/), [Snowpack](https://www.snowpack.dev/), and [Vite](https://vitejs.dev/) effectively.
+[Another PR](https://github.com/facebook/jest/issues/9504) enabled [`transform`s](/docs/configuration#transform-objectstring-pathtotransformer--pathtotransformer-object) to be asynchronous, a requirement to support transpilation through tools such as [esbuild](https://esbuild.github.io/), [Snowpack](https://www.snowpack.dev/), and [Vite](https://vitejs.dev/) effectively.
 
 ## Flipping defaults
 
 Up until now, if you were using Jest in its default configuration, you were—perhaps unknowingly—running some code forked many years ago from the test runner [Jasmine 2.0](https://jasmine.github.io/2.0/introduction) that provides test framework functions such as `describe`, `it`, and `beforeEach`. In 2017, [Aaron Abramov](https://github.com/aaronabramov) [initially wrote](https://github.com/facebook/jest/pull/3668) a **replacement for the Jasmine code** called `jest-circus`, meant to improve error messages, maintainability, and extensibility.  
-After years of large-scale use at Facebook and of course in Jest itself, as well as recent adoption in `create-react-app`, we are now confident that `jest-circus` is highly compatible with `jest-jasmine2` and should work in most environments with little to no migration work. There may be minor differences in execution order and strictness, but we expect no major upgrade difficulties other than for code relying on Jasmine-specific APIs such as `jasmine.getEnv()`. If you rely extensively on such APIs, you can opt back in to the Jasmine-based test runner by [configuring](/docs/en/configuration#testrunner-string) `"testRunner": "jest-jasmine2"`.
+After years of large-scale use at Facebook and of course in Jest itself, as well as recent adoption in `create-react-app`, we are now confident that `jest-circus` is highly compatible with `jest-jasmine2` and should work in most environments with little to no migration work. There may be minor differences in execution order and strictness, but we expect no major upgrade difficulties other than for code relying on Jasmine-specific APIs such as `jasmine.getEnv()`. If you rely extensively on such APIs, you can opt back in to the Jasmine-based test runner by [configuring](/docs/configuration#testrunner-string) `"testRunner": "jest-jasmine2"`.
 
-Running tests in a [JSDOM environment](/docs/en/configuration#testenvironment-string) incurs a significant performance overhead. Because this was the default behavior of Jest unless otherwise configured up until now, users who are writing Node apps, for example, may not even know they are given an expensive DOM environment that they do not even need.  
-For this reason, we are **changing the default test environment** from `"jsdom"` to `"node"`. If you are affected by this change because you use DOM APIs and do not have the test environment explicitly configured, you should be receiving an error when e.g. `document` is accessed, and you can configure `"testEnvironment": "jsdom"` or use [per-file environment configuration](/docs/en/configuration#testenvironment-string) to resolve this.  
-For mixed projects where some tests require a DOM environment but others don't, we recommend using the fast `"node"` environment by default and declaring exactly those tests that need the DOM using [docblocks](/docs/en/configuration#testenvironment-string).  
+Running tests in a [JSDOM environment](/docs/configuration#testenvironment-string) incurs a significant performance overhead. Because this was the default behavior of Jest unless otherwise configured up until now, users who are writing Node apps, for example, may not even know they are given an expensive DOM environment that they do not even need.  
+For this reason, we are **changing the default test environment** from `"jsdom"` to `"node"`. If you are affected by this change because you use DOM APIs and do not have the test environment explicitly configured, you should be receiving an error when e.g. `document` is accessed, and you can configure `"testEnvironment": "jsdom"` or use [per-file environment configuration](/docs/configuration#testenvironment-string) to resolve this.  
+For mixed projects where some tests require a DOM environment but others don't, we recommend using the fast `"node"` environment by default and declaring exactly those tests that need the DOM using [docblocks](/docs/configuration#testenvironment-string).  
 In the next major, we plan to also eliminate `jest-jasmine2` and `jest-environment-jsdom` from the Jest dependency tree and require them to be installed explicitly, so that many users can profit from a smaller install size with less clutter that they don't need.
 
-Another default that we are changing affects Fake Timers aka [Timer Mocks](/docs/en/timer-mocks). We introduced an opt-in "modern" implementation of Fake Timers in Jest 26 accessed transparently through the same API, but with much more comprehensive mocking, such as for `Date` and `queueMicrotask`.  
-This **modern fake timers implementation will now be the default**. If you are among the unlucky few who are affected by the subtle implementation differences too heavily to migrate, you can get back the old implementation using `jest.useFakeTimers("legacy")` or, if you are enabling fake timers globally via [configuration](/docs/en/configuration#timers-string), `"timers": "legacy"`.
+Another default that we are changing affects Fake Timers aka [Timer Mocks](/docs/timer-mocks). We introduced an opt-in "modern" implementation of Fake Timers in Jest 26 accessed transparently through the same API, but with much more comprehensive mocking, such as for `Date` and `queueMicrotask`.  
+This **modern fake timers implementation will now be the default**. If you are among the unlucky few who are affected by the subtle implementation differences too heavily to migrate, you can get back the old implementation using `jest.useFakeTimers("legacy")` or, if you are enabling fake timers globally via [configuration](/docs/configuration#timers-string), `"timers": "legacy"`.
 
 ## Features coming with breaking changes