diff --git a/pages/asynchronous-work/discover-promises-in-nodejs.md b/pages/asynchronous-work/discover-promises-in-nodejs.md index 8af7448..7c4b237 100644 --- a/pages/asynchronous-work/discover-promises-in-nodejs.md +++ b/pages/asynchronous-work/discover-promises-in-nodejs.md @@ -365,7 +365,7 @@ console.log('Synchronous task executed'); ### `setImmediate()` -`setImmediate()` schedules a callback to be executed in the check phase of the Node.js [event loop](/asynchronous-work/event-loop-timers-and-nexttick), which runs after the poll phase, where most I/O callbacks are processed. +`setImmediate()` schedules a callback to be executed in the check phase of the Node.js [event loop](/learn/asynchronous-work/event-loop-timers-and-nexttick), which runs after the poll phase, where most I/O callbacks are processed. ```js setImmediate(() => { @@ -383,4 +383,4 @@ console.log('Synchronous task executed'); Because these tasks execute outside of the current synchronous flow, uncaught exceptions inside these callbacks won't be caught by surrounding `try/catch` blocks and may crash the application if not properly managed (e.g., by attaching `.catch()` to Promises or using global error handlers like `process.on('uncaughtException')`). -For more information on the Event Loop, and the execution order of various phases, please see the related article, [The Node.js Event Loop](/asynchronous-work/event-loop-timers-and-nexttick). +For more information on the Event Loop, and the execution order of various phases, please see the related article, [The Node.js Event Loop](/learn/asynchronous-work/event-loop-timers-and-nexttick). diff --git a/pages/asynchronous-work/overview-of-blocking-vs-non-blocking.md b/pages/asynchronous-work/overview-of-blocking-vs-non-blocking.md index adcfaee..d63114f 100644 --- a/pages/asynchronous-work/overview-of-blocking-vs-non-blocking.md +++ b/pages/asynchronous-work/overview-of-blocking-vs-non-blocking.md @@ -7,7 +7,7 @@ authors: ovflowd, HassanBahati This overview covers the difference between **blocking** and **non-blocking** calls in Node.js. This overview will refer to the event loop and libuv but no prior knowledge of those topics is required. Readers are assumed to have a -basic understanding of the JavaScript language and Node.js [callback pattern](/asynchronous-work/javascript-asynchronous-programming-and-callbacks). +basic understanding of the JavaScript language and Node.js [callback pattern](/learn/asynchronous-work/javascript-asynchronous-programming-and-callbacks). > "I/O" refers primarily to interaction with the system's disk and > network supported by [libuv](https://libuv.org/). diff --git a/pages/asynchronous-work/understanding-processnexttick.md b/pages/asynchronous-work/understanding-processnexttick.md index 5c91816..634b6dd 100644 --- a/pages/asynchronous-work/understanding-processnexttick.md +++ b/pages/asynchronous-work/understanding-processnexttick.md @@ -23,4 +23,4 @@ Calling `setTimeout(() => {}, 0)` will execute the function at the end of next t Use `nextTick()` when you want to make sure that in the next event loop iteration that code is already executed. -To learn more about the order of execution and how the event loop works, check out [the dedicated article](/asynchronous-work/event-loop-timers-and-nexttick) +To learn more about the order of execution and how the event loop works, check out [the dedicated article](/learn/asynchronous-work/event-loop-timers-and-nexttick) diff --git a/pages/diagnostics/live-debugging/index.md b/pages/diagnostics/live-debugging/index.md index 03b9311..d116ce4 100644 --- a/pages/diagnostics/live-debugging/index.md +++ b/pages/diagnostics/live-debugging/index.md @@ -18,4 +18,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](/diagnostics/live-debugging/using-inspector) +- [Using Inspector](/learn/diagnostics/live-debugging/using-inspector) diff --git a/pages/diagnostics/live-debugging/using-inspector.md b/pages/diagnostics/live-debugging/using-inspector.md index e0365d5..f2022d8 100644 --- a/pages/diagnostics/live-debugging/using-inspector.md +++ b/pages/diagnostics/live-debugging/using-inspector.md @@ -9,4 +9,4 @@ of the application as it handles a business-critical workload. ## How To -[Debugging Node.js](/diagnostics/debugging) +[Debugging Node.js](/learn/diagnostics/debugging) diff --git a/pages/diagnostics/memory/index.md b/pages/diagnostics/memory/index.md index 024dc99..6b84c8f 100644 --- a/pages/diagnostics/memory/index.md +++ b/pages/diagnostics/memory/index.md @@ -10,7 +10,7 @@ multi-tenant, business critical, and long-running, providing an accessible and efficient way of finding a memory leak is essential. You can also fine-tune memory to get specific results. Check out -[Understanding and Tuning Memory](/diagnostics/memory/understanding-and-tuning-memory) for more details. +[Understanding and Tuning Memory](/learn/diagnostics/memory/understanding-and-tuning-memory) for more details. ### Symptoms @@ -47,6 +47,6 @@ type of objects take and what variables are preventing them from being garbage collected. It can also help to know the allocation pattern of our program over time. -- [Using Heap Profiler](/diagnostics/memory/using-heap-profiler/) -- [Using Heap Snapshot](/diagnostics/memory/using-heap-snapshot/) -- [GC Traces](/diagnostics/memory/using-gc-traces) +- [Using Heap Profiler](/learn/diagnostics/memory/using-heap-profiler/) +- [Using Heap Snapshot](/learn/diagnostics/memory/using-heap-snapshot/) +- [GC Traces](/learn/diagnostics/memory/using-gc-traces/) diff --git a/pages/diagnostics/poor-performance/index.md b/pages/diagnostics/poor-performance/index.md index c4511c4..45b1742 100644 --- a/pages/diagnostics/poor-performance/index.md +++ b/pages/diagnostics/poor-performance/index.md @@ -22,5 +22,5 @@ the others. When we do this locally, we usually try to optimize our code. This document provides two simple ways to profile a Node.js application: -- [Using V8 Sampling Profiler](/diagnostics/profiling) -- [Using Linux Perf](/diagnostics/poor-performance/using-linux-perf) +- [Using V8 Sampling Profiler](/learn/diagnostics/profiling) +- [Using Linux Perf](/learn/diagnostics/poor-performance/using-linux-perf) diff --git a/pages/diagnostics/poor-performance/using-linux-perf.md b/pages/diagnostics/poor-performance/using-linux-perf.md index 1ae76de..930386b 100644 --- a/pages/diagnostics/poor-performance/using-linux-perf.md +++ b/pages/diagnostics/poor-performance/using-linux-perf.md @@ -67,16 +67,16 @@ visualization. ![Example nodejs flamegraph](https://user-images.githubusercontent.com/26234614/129488674-8fc80fd5-549e-4a80-8ce2-2ba6be20f8e8.png) -To generate a flamegraph from this result, follow [this tutorial](/diagnostics/flame-graphs#create-a-flame-graph-with-system-perf-tools) +To generate a flamegraph from this result, follow [this tutorial](/learn/diagnostics/flame-graphs#create-a-flame-graph-with-system-perf-tools) from step 6. Because `perf` output is not a Node.js specific tool, it might have issues with how JavaScript code is optimized in -Node.js. See [perf output issues](/diagnostics/flame-graphs#perf-output-issues) for a +Node.js. See [perf output issues](/learn/diagnostics/flame-graphs#perf-output-issues) for a further reference. ## Useful Links -- [Flame Graphs](/diagnostics/flame-graphs) +- [Flame Graphs](/learn/diagnostics/flame-graphs) - https://www.brendangregg.com/blog/2014-09-17/node-flame-graphs-on-linux.html - https://perf.wiki.kernel.org/index.php/Main_Page - https://blog.rafaelgss.com.br/node-cpu-profiler diff --git a/pages/getting-started/how-much-javascript-do-you-need-to-know-to-use-nodejs.md b/pages/getting-started/how-much-javascript-do-you-need-to-know-to-use-nodejs.md index 104759d..e1c6ea2 100644 --- a/pages/getting-started/how-much-javascript-do-you-need-to-know-to-use-nodejs.md +++ b/pages/getting-started/how-much-javascript-do-you-need-to-know-to-use-nodejs.md @@ -21,7 +21,7 @@ As a beginner, it's hard to get to a point where you are confident enough in you - [Arrays](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array) - [Template Literals](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals) - [Strict Mode](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode) -- [ECMAScript 2015 (ES6) and beyond](/getting-started/ecmascript-2015-es6-and-beyond) +- [ECMAScript 2015 (ES6) and beyond](/learn/getting-started/ecmascript-2015-es6-and-beyond) - [Asynchronous JavaScript](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Async_JS) With those concepts in mind, you are well on your road to become a proficient JavaScript developer, in both the browser and in Node.js. diff --git a/pages/typescript/publishing-a-ts-package.md b/pages/typescript/publishing-a-ts-package.md index fe6efad..a917316 100644 --- a/pages/typescript/publishing-a-ts-package.md +++ b/pages/typescript/publishing-a-ts-package.md @@ -8,7 +8,7 @@ This article covers items regarding TypeScript publishing specifically. Publishi Some important things to note: -- Everything from [Publishing a package](../package-management/publishing-a-package) applies here. +- Everything from [Publishing a package](/learn/modules/publishing-a-package) applies here. - Fields like `main` operate on _published_ content, so when TypeScript source-code is transpiled to JavaScript, JavaScript is the published content and `main` would point to a JavaScript file with a JavaScript file extension (ex `main.ts` → `"main": "main.js"`). - Fields like `scripts.test` operate on source-code, so they would use the file extensions of the source code (ex `"test": "node --test './src/**/*.test.ts'`). diff --git a/pages/typescript/transpile.md b/pages/typescript/transpile.md index 2e3dc20..6e5f59f 100644 --- a/pages/typescript/transpile.md +++ b/pages/typescript/transpile.md @@ -36,7 +36,7 @@ const isJustineAnAdult = isAdult(justine); **Step 2:** Install TypeScript locally using a package manager: -In this example we're going to use npm, you can check [our introduction to the npm package manager](/package-management/an-introduction-to-the-npm-package-manager) for more information. +In this example we're going to use npm, you can check [our introduction to the npm package manager](/learn/getting-started/an-introduction-to-the-npm-package-manager) for more information. ```bash displayName="Install TypeScript locally" npm i -D typescript # -D is a shorthand for --save-dev