Moving all chapter and book frontmatter files into the top level of the directory

Author: hackermatthew

Diff for: atlas.json

@@ -1,19 +1,19 @@
 {
   "branch": "master",
   "files": [
-    "sections/cover.html",
-    "sections/toc.html",
-    "sections/foreword.asciidoc",
-    "sections/preface.asciidoc",
-    "chapters/ch01.asciidoc",
-    "chapters/ch02.asciidoc",
-    "chapters/ch03.asciidoc",
-    "chapters/ch04.asciidoc",
-    "chapters/ch05.asciidoc",
-    "chapters/ch06.asciidoc",
-    "chapters/ch07.asciidoc",
-    "chapters/ch08.asciidoc",
-    "chapters/ch09.asciidoc"
+    "cover.html",
+    "toc.html",
+    "foreword.asciidoc",
+    "preface.asciidoc",
+    "ch01.asciidoc",
+    "ch02.asciidoc",
+    "ch03.asciidoc",
+    "ch04.asciidoc",
+    "ch05.asciidoc",
+    "ch06.asciidoc",
+    "ch07.asciidoc",
+    "ch08.asciidoc",
+    "ch09.asciidoc"
   ],
   "formats": {
     "pdf": {
@@ -61,4 +61,4 @@
   "print_isbn13": "",
   "lang": "en",
   "accent_color": "cmyk(100%, 3%, 50%, 0%)"
-}
+}

Diff for: chapters/ch01.asciidoc renamed to ch01.asciidoc

@@ -98,7 +98,7 @@ console.log(double(3))
 
 To the right of the source code we've entered, you'll see the transpiled ES5 equivalent. As you update your source code, the transpiled result is also updated in real-time.
 
-image::../images/c01g01-babel-repl.png["Babel REPL"]
+image::images/c01g01-babel-repl.png["Babel REPL"]
 
 The Babel REPL is an effective companion as a way of trying out some of the features introduced in this book. However, note that Babel doesn't transpile new built-ins, such as `Symbol`, `Proxy` and `WeakMap`. Those references are instead left untouched, and it's up to the runtime executing the Babel output to provide those built-ins. If we want to support runtimes that haven't yet implemented these built-ins, we could import the `babel-polyfill` package in our code.
 
@@ -283,7 +283,7 @@ if(false){}
 
 When we run the `lint` script, ESLint describes everything that's wrong with the file.
 
-image::../images/c01g02-eslint-cli.png["Validating a piece of source code through ESLint."]
+image::images/c01g02-eslint-cli.png["Validating a piece of source code through ESLint."]
 
 ESLint is able to fix most style problems automatically if we pass in a `--fix` flag. Add the following script to your `package.json`.
 

Diff for: chapters/ch02.asciidoc renamed to ch02.asciidoc

@@ -113,7 +113,7 @@ When we chain promises, we need to understand that `p1.then(r1).then(r2)` create
 
 Figuring out the tree-like nature of promises is the key to unlocking a deep understanding of how promises behave. To this end, I've created an online tool called Promisees you can use to play around with promise chains while visualizing the tree structure they leave behind.
 
-image::../images/c04g01-promisees.png["Promisees lets you write a piece of code and visualize how the underlying graph evolves as promises are settled in fulfillment or rejection."]
+image::images/c04g01-promisees.png["Promisees lets you write a piece of code and visualize how the underlying graph evolves as promises are settled in fulfillment or rejection."]
 
 You can find Promisees at https://mjavascript.com/out/promisees.
 ====
@@ -222,11 +222,11 @@ const p3 = p2.catch(err => console.error(err))
 
 Here is another situation where it might help you to think of promises as a tree-like data structure. In the following illustration it becomes clear that, given the error originates in the `p2` node, we couldn't notice it by attaching a rejection reaction to `p1`.
 
-image::../images/c04g02-promise-split-chain.png["The p3 rejection handler in this example won't be able to catch the failure in p2's reaction, since it reacts to p1 instead of p2."]
+image::images/c04g02-promise-split-chain.png["The p3 rejection handler in this example won't be able to catch the failure in p2's reaction, since it reacts to p1 instead of p2."]
 
 In order for the reaction to handle the rejection in `p2`, we'd have to attach the reaction to `p2` instead.
 
-image::../images/c04g03-promise-serial-chain.png["In this example, p3 reacts to p2. This enables p3 to handle the rejection that arises in p2."]
+image::images/c04g03-promise-serial-chain.png["In this example, p3 reacts to p2. This enables p3 to handle the rejection that arises in p2."]
 
 We've established that the promise you attach your reactions onto is important, as it determines what errors it can capture and what errors it can not. It's also worth noting that as long as an error remains uncaught in a promise chain, a rejection handler will be able to capture it. In the following example we've introduced an intermediary `.then` call in between `p2`, where the error originated; and `p4`, where we attach the rejection reaction. When `p2` settles with a rejection, `p3` becomes settled with a rejection as it depends on `p2` directly. When `p3` settles with a rejection, the rejection handler in `p4` fires.
 
@@ -306,7 +306,7 @@ Here is an enumeration of what is going on as that piece of code is executed.
 
 You should think of promises as a tree structure. This bears repetition: you should think of promises as a tree structurefootnoteref:[promisees,I wrote an online visualization tool called Promisees where you can see the tree structure underlying a Promise chain: https://mjavascript.com/out/promisees.].
 
-image::../images/c04g04-promise-chain.png["Promisees can help us visualize how the fetch promise is fulfilled, but p2 is rejected, thus triggering any rejection reactions attached to it. Given p3 is fulfilled, rejection reactions like p4 are never executed."]
+image::images/c04g04-promise-chain.png["Promisees can help us visualize how the fetch promise is fulfilled, but p2 is rejected, thus triggering any rejection reactions attached to it. Given p3 is fulfilled, rejection reactions like p4 are never executed."]
 
 It all starts with a single promise, which we'll next learn how to construct. Then you add branches with `.then` or `.catch`. You can tack as many `.then` or `.catch` calls as you want onto each branch, creating new branches, and so on.
 
@@ -810,7 +810,7 @@ This sort of abstraction of complexity into another function often helps keep co
 ====
 Iterators don't have any knowledge that the sequences they produce are infinite. In a similar situation to the famous halting problem, there is no way of knowing whether the sequence is infinite or not in code.
 
-image::../images/c04g05-halting-problem.png["The halting problem depicted in an XKCD comic: https://mjavascript.com/out/xkcd-1266."]
+image::images/c04g05-halting-problem.png["The halting problem depicted in an XKCD comic: https://mjavascript.com/out/xkcd-1266."]
 
 You typically have a good idea of whether a sequence is infinite or not. Whenever you have an infinite sequence it's up to you to add an escape condition that ensures the program won't crash in an attempt to loop over every single value in the sequence. While `for..of` won't run into the problem unless there's no escape condition, using mechanisms such as spread or `Array.from` would immediately result in the program crashing into an infinite loop in the case of infinite sequences.
 ====

Diff for: chapters/ch03.asciidoc renamed to ch03.asciidoc

@@ -90,7 +90,7 @@ console.log(html)
 
 The following screenshot shows our tiny application in action.
 
-image::../images/c08g01-grocery-item.png["Printing an item for our grocery shopping list"]
+image::images/c08g01-grocery-item.png["Printing an item for our grocery shopping list"]
 
 The next template we'll make renders the grocery list itself. It receives an array of items, and renders each of them by reusing the `item.js` template from the previous code snippet.
 
@@ -122,7 +122,7 @@ console.log(html)
 
 The following screenshot shows our updated application in all its glory.
 
-image::../images/c08g02-grocery-list.png["Printing a grocery shopping list"]
+image::images/c08g02-grocery-list.png["Printing a grocery shopping list"]
 
 In the examples so far, we've written short modules that are only concerned with producing an HTML view after matching a `model` object with the corresponding view template. A simple API encourages reusability, which is why we're easily able to render the items for a list by mapping their models to the `item.js` templating function, and joining their HTML representations with newlines.
 
@@ -155,7 +155,7 @@ console.log(render('list', [{
 }]))
 ----
 
-image::../images/c08g03-dynamic-render.png["Printing different views through a normalized render function."]
+image::images/c08g03-dynamic-render.png["Printing different views through a normalized render function."]
 
 Moving on, you'll notice that ES6 modules are somewhat influenced by CommonJS. In the next few sections we'll look at `export` and `import` statements, and learn how ESM is compatible with CJS.