docs(learn): Migrate diagnostics user journey from guide to learn section (nodejs#6291)

* fix: redirect old guide links to new learn section

- redirect old guide links to new learn section
- fix the focus on click to the #filtering-out-nodejs-internal-functions

* docs(learn): migrate diagnostics user journey to learn

* doc(learn): add redirect changes

* fix(learn): fix redirect url

* doc(learn): move internal links to the nav and fix redirect

* doc(learn): remove toc from files

* docs(learn): change javascript snippets to js

Author: paulobelucci

i18n/locales/en.json

@@ -87,6 +87,10 @@
         "diagnostics": {
           "links": {
             "diagnostics": "Diagnostics",
+            "userJourney": "User Journey",
+            "memory": "Memory",
+            "liveDebugging": "Live Debugging",
+            "poorPerformance": "Poor Performance",
             "flameGraphs": "Flame Graphs"
           }
         }

navigation.json

@@ -234,6 +234,22 @@
         "diagnostics": {
           "label": "components.navigation.learn.diagnostics.links.diagnostics",
           "items": {
+            "userJourney": {
+              "link": "/learn/diagnostics/user-journey",
+              "label": "components.navigation.learn.diagnostics.links.userJourney"
+            },
+            "memory": {
+              "link": "/learn/diagnostics/memory",
+              "label": "components.navigation.learn.diagnostics.links.memory"
+            },
+            "liveDebugging": {
+              "link": "/learn/diagnostics/live-debugging",
+              "label": "components.navigation.learn.diagnostics.links.liveDebugging"
+            },
+            "poorPerformance": {
+              "link": "/learn/diagnostics/poor-performance",
+              "label": "components.navigation.learn.diagnostics.links.poorPerformance"
+            },
             "flameGraphs": {
               "link": "/learn/diagnostics/flame-graphs",
               "label": "components.navigation.learn.diagnostics.links.flameGraphs"

pages/en/guides/backpressuring-in-streams.md

@@ -36,7 +36,7 @@ pipes, sockets, and signals. In Node.js, we find a similar mechanism called
 part of the internal codebase utilizes that module. As a developer, you
 are more than encouraged to use them too!
 
-```javascript
+```js
 const readline = require('readline');
 
 // process.stdin and process.stdout are both instances of Streams.
@@ -67,7 +67,7 @@ While that will take a few minutes to complete, in another shell we may run
 a script that takes Node.js' module [`zlib`][], that wraps around another
 compression tool, [`gzip(1)`][].
 
-```javascript
+```js
 const gzip = require('zlib').createGzip();
 const fs = require('fs');
 
@@ -95,7 +95,7 @@ cleaning up and provide a callback when the pipeline is complete.
 
 Here is an example of using pipeline:
 
-```javascript
+```js
 const { pipeline } = require('stream');
 const fs = require('fs');
 const zlib = require('zlib');
@@ -120,7 +120,7 @@ pipeline(
 
 You can also call [`promisify`][] on pipeline to use it with `async` / `await`:
 
-```javascript
+```js
 const stream = require('stream');
 const fs = require('fs');
 const zlib = require('zlib');
@@ -156,7 +156,7 @@ trying to compress a file and write it to our hard disk, backpressure will
 occur because the write disk will not be able to keep up with the speed from
 the read.
 
-```javascript
+```js
 // Secretly the stream is saying: "whoa, whoa! hang on, this is way too much!"
 // Data will begin to build up on the read-side of the data buffer as
 // `write` tries to keep up with the incoming data flow.
@@ -417,7 +417,7 @@ stream:
 In this case, your output from your [`Readable`][] stream will enter in the
 [`Transform`][] and will pipe into the [`Writable`][].
 
-```javascript
+```js
 Readable.pipe(Transformable).pipe(Writable);
 ```
 
@@ -477,7 +477,7 @@ source. Otherwise, it will continue without pause.
 
 Here is an example of bad practice using [`.push()`][]:
 
-```javascript
+```js
 // This is problematic as it completely ignores return value from push
 // which may be a signal for backpressure from the destination stream!
 class MyReadable extends Readable {
@@ -495,7 +495,7 @@ backpressure. In this counter-example of good practice, the application's code
 forces data through whenever it is available (signaled by the
 [`'data'` event][]):
 
-```javascript
+```js
 // This ignores the backpressure mechanisms Node.js has set in place,
 // and unconditionally pushes through data, regardless if the
 // destination stream is ready for it or not.
@@ -504,7 +504,7 @@ readable.on('data', data => writable.write(data));
 
 Here's an example of using [`.push()`][] with a Readable stream.
 
-```javascript
+```js
 const { Readable } = require('stream');
 
 // Create a custom Readable stream
@@ -551,7 +551,7 @@ However, when we want to use a [`Writable`][] directly, we must respect the
 
 <!-- eslint-disable indent -->
 
-```javascript
+```js
 // This writable is invalid because of the async nature of JavaScript callbacks.
 // Without a return statement for each callback prior to the last,
 // there is a great chance multiple callbacks will be called.
@@ -573,7 +573,7 @@ There are also some things to look out for when implementing [`._writev()`][].
 The function is coupled with [`.cork()`][], but there is a common mistake when
 writing:
 
-```javascript
+```js
 // Using .uncork() twice here makes two calls on the C++ layer, rendering the
 // cork/uncork technique useless.
 ws.cork();

pages/en/guides/diagnostics/index.md

@@ -116,15 +116,15 @@ If your callback takes a different number of steps depending on its arguments, t
 
 Example 1: A constant-time callback.
 
-```javascript
+```js
 app.get('/constant-time', (req, res) => {
   res.sendStatus(200);
 });
 ```
 
 Example 2: An `O(n)` callback. This callback will run quickly for small `n` and more slowly for large `n`.
 
-```javascript
+```js
 app.get('/countToN', (req, res) => {
   let n = req.query.n;
 
@@ -139,7 +139,7 @@ app.get('/countToN', (req, res) => {
 
 Example 3: An `O(n^2)` callback. This callback will still run quickly for small `n`, but for large `n` it will run much more slowly than the previous `O(n)` example.
 
-```javascript
+```js
 app.get('/countToN2', (req, res) => {
   let n = req.query.n;
 
@@ -191,7 +191,7 @@ The exponential behavior is triggered when there is a mismatch but Node.js can't
 
 Here is an example vulnerable regexp exposing its server to REDOS:
 
-```javascript
+```js
 app.get('/redos-me', (req, res) => {
   let filePath = req.query.filePath;
 
@@ -269,7 +269,7 @@ If your server manipulates JSON objects, particularly those from a client, you s
 
 Example: JSON blocking. We create an object `obj` of size 2^21 and `JSON.stringify` it, run `indexOf` on the string, and then JSON.parse it. The `JSON.stringify`'d string is 50MB. It takes 0.7 seconds to stringify the object, 0.03 seconds to indexOf on the 50MB string, and 1.3 seconds to parse the string.
 
-```javascript
+```js
 var obj = { a: 1 };
 var niter = 20;
 
@@ -314,15 +314,15 @@ For a simple example, suppose you want to compute the average of the numbers `1`
 
 Example 1: Un-partitioned average, costs `O(n)`
 
-```javascript
+```js
 for (let i = 0; i < n; i++) sum += i;
 let avg = sum / n;
 console.log('avg: ' + avg);
 ```
 
 Example 2: Partitioned average, each of the `n` asynchronous steps costs `O(1)`.
 
-```javascript
+```js
 function asyncAvg(n, avgCB) {
   // Save ongoing sum in JS closure.
   var sum = 0;

pages/en/guides/dont-block-the-event-loop.md

@@ -10,7 +10,6 @@ layout: docs.hbs
 ## General
 
 - [Easy profiling for Node.js Applications](/guides/simple-profiling/)
-- [Diagnostics - User Journey](/guides/diagnostics/)
 - [Security Best Practices](/guides/security/)
 
 ## Node.js core concepts

pages/en/guides/index.md

@@ -426,7 +426,7 @@ The [OpenSSF][] is leading several initiatives that can be very useful, especial
 [Slowloris]: https://en.wikipedia.org/wiki/Slowloris_(computer_security)
 [`http.Server`]: https://nodejs.org/api/http.html#class-httpserver
 [http docs]: https://nodejs.org/api/http.html
-[--inspect switch]: /guides/debugging-getting-started/
+[--inspect switch]: /learn/debugging-getting-started/
 [same-origin policy]: /guides/debugging-getting-started/
 [DNS Rebinding wiki]: https://en.wikipedia.org/wiki/DNS_rebinding
 [files property]: https://docs.npmjs.com/cli/v8/configuring-npm/package-json#files

pages/en/guides/security/index.md

@@ -30,7 +30,7 @@ To illustrate the use of the tick profiler, we will work with a simple Express
 application. Our application will have two handlers, one for adding new users to
 our system:
 
-```javascript
+```js
 app.get('/newUser', (req, res) => {
   let username = req.query.username || '';
   const password = req.query.password || '';
@@ -52,7 +52,7 @@ app.get('/newUser', (req, res) => {
 
 and another for validating user authentication attempts:
 
-```javascript
+```js
 app.get('/auth', (req, res) => {
   let username = req.query.username || '';
   const password = req.query.password || '';
@@ -217,7 +217,7 @@ requests while computing a hash.
 To remedy this issue, you make a small modification to the above handlers to use
 the asynchronous version of the pbkdf2 function:
 
-```javascript
+```js
 app.get('/auth', (req, res) => {
   let username = req.query.username || '';
   const password = req.query.password || '';
@@ -287,4 +287,4 @@ You may also find [how to create a flame graph][diagnostics flamegraph] helpful.
 
 [profiler inside V8]: https://v8.dev/docs/profile
 [benefits of asynchronous programming]: https://nodesource.com/blog/why-asynchronous
-[diagnostics flamegraph]: /guides/diagnostics-flamegraph/
+[diagnostics flamegraph]: /learn/diagnostics/flame-graphs

pages/en/guides/simple-profiling.md

@@ -39,7 +39,7 @@ Now let's get to work.
    ```
 
 4. Disregard warnings unless they're saying you can't run perf due to missing packages; you may get some warnings about not being able to access kernel module samples which you're not after anyway.
-5. Run `perf script > perfs.out` to generate the data file you'll visualize in a moment. It's useful to [apply some cleanup](#filtering-out-node-js-internal-functions) for a more readable graph
+5. Run `perf script > perfs.out` to generate the data file you'll visualize in a moment. It's useful to [apply some cleanup](#filtering-out-nodejs-internal-functions) for a more readable graph
 6. Install stackvis if not yet installed `npm i -g stackvis`
 7. Run `stackvis perf < perfs.out > flamegraph.htm`
 

pages/en/learn/diagnostics/flame-graphs.md

@@ -1,15 +1,10 @@
 ---
 title: Live Debugging
-layout: docs.hbs
+layout: learn.hbs
 ---
 
 # Live Debugging
 
-- [Live Debugging](#live-debugging)
-  - [My application doesn’t behave as expected](#my-application-doesnt-behave-as-expected)
-    - [Symptoms](#symptoms)
-    - [Debugging](#debugging)
-
 In this document you can learn about how to live debug a Node.js process.
 
 ## My application doesn’t behave as expected
@@ -28,4 +23,4 @@ application executes for a certain trigger like an incoming HTTP request. They
 may also want to step through the code and control the execution as well as
 inspect what values variables hold in memory.
 
-- [Using Inspector](/guides/diagnostics/live-debugging/using-inspector)
+- [Using Inspector](/learn/diagnostics/live-debugging/using-inspector)