Using rm instead of rmDir

package.json

@@ -6,7 +6,7 @@
   "main": "index.js",
   "scripts": {
     "dev": "concurrently --kill-others -n Build,Serve -c auto \"npm run watch-build\" \"npm run serve\"",
-    "watch-build": "nodemon --watch notes --watch src --watch markdown.ts --exec \"npm run build && npm run generate-blog\"",
+    "watch-build": "nodemon --ext js,ts,json,md --watch notes --watch src --watch packages/@zblog/toolchain/src --watch markdown.ts --exec \"npm run build --workspaces && npm run build && npm run generate-blog\"",
     "build": "tsc -p tsconfig.json",
     "serve": "serve dist",
     "generate-blog": "node bin/index.js",

packages/@zblog/toolchain/src/toolchain-helpers.ts

@@ -1,7 +1,7 @@
 import fs from "fs";
 export const destructivelyRecreateDirectory = (directoryPath: string) => {
   if (fs.existsSync(directoryPath)) {
-    fs.rmdirSync(directoryPath, { recursive: true });
+    fs.rmSync(directoryPath, { recursive: true });
   }
   fs.mkdirSync(directoryPath, { recursive: true });
 };

readme.md

@@ -4,7 +4,7 @@
 
 1. Clone the repository.
 1. Install node 20.
-1. Install all npmjs packages `npm run install --workspaces`
+1. Install all npmjs packages `npm run install`
 1. Build all workspaces `npm run build --workspaces`
 1. Generate site `npm run generate-blog`
 1. Start dev server `npm run dev`

src/notes/2-ideas/note.md

@@ -1,17 +0,0 @@
-# Ideas
-
-_2023-09-16_
-
-This morning I was out for a bike ride.
-
-It's something that i really enjoy, and I usually pair it with listening to a couple of episodes from my favorite podcasts (today it was [Syntax](/404)).
-After 30 minutes or so i find that I usually enter some kind of creative state and zone in and of actually listening to the podcast (if it isn't very interesting) and coming up with project ideas.
-Today I came up with one that i thought was pretty neat, it most probably already exists in another shape or form.
-
-There should be a tool that lets you browse your image library based on location.
-You index the location exif data from your whole library and plot that on a map.
-You then draw hotspots on the map where images are present, pressing one reveals the images.
-
-Couple this with some nice filtering and perhaps image recognision and it would be pretty neat way to find that picture of that place that you don't really remember where it was physically, but you have a vague recognision of when you took it and what it captured.
-
-The reason I came up with this is that I sometimes stumble upon beautiful or cool places that I would like to revisit on foot, and while I track my rides with GPS I don't have a system for leaving points of interest to then revisit. Since what I guess is most phones already capture this information, why not put it to good use?

src/notes/3-markdown-parser/note.md

@@ -1,5 +1,7 @@
 # Markdown parser
 
+## Part 1
+
 _2023-09-16_
 
 While traveling today i thought about ways to structure my markdown parser.
@@ -35,3 +37,25 @@ In this case the heading is a single line symbol, so the symbol strips the line
 The static symbol instance now returns an instance of a header symbol which we can save to a list for later rendering.
 
 Calling render on a symbol should result in a html string composed of itself plus any child symbols recursivly.
+
+## Part 2
+
+The markdown parser is kind of going according to plan. I realised that with the appoach I decided to take I'm going to need a couple of more steps than just going line by line and deciding what type of element each should be.
+
+Let's take an example:
+
+```
+Some **bold** text and then some _cursive_ text
+```
+
+This is not only a text line but it has both bold and cursive text.
+
+So in addition to parsing the markdown files line by line (stage 1), I implemented stage 2 processing with the purpose of expanding the identified elements into child elements. So when a text row element containing the text in the example above is requested to peform its stage 2 processing it will take its text and run it once more through the stage 1 processing to divide it into new symbols. It then calls stage 2 processing of all its new children to make sure every element has been processed.
+
+In the end we should have gone from `TextLine` to `PlainText, Bold, PlainText , Italic, Plaintext`.
+
+Here's the result.
+
+Some **bold** text and then some _cursive_ text
+
+Next up is stage 3 processing which will affect elements depending on their position in the list of elements.

src/notes/4-markdown-parser-part-2/note.md

@@ -1,21 +0,0 @@
-# Markdown parser part 2
-
-The markdown parser is kind of going according to plan. I realised that with the appoach I decided to take I'm going to need a couple of more steps than just going line by line and deciding what type of element each should be.
-
-Let's take an example:
-
-```
-Some **bold** text and then some _cursive_ text
-```
-
-This is not only a text line but it has both bold and cursive text.
-
-So in addition to parsing the markdown files line by line (stage 1), I implemented stage 2 processing with the purpose of expanding the identified elements into child elements. So when a text row element containing the text in the example above is requested to peform its stage 2 processing it will take its text and run it once more through the stage 1 processing to divide it into new symbols. It then calls stage 2 processing of all its new children to make sure every element has been processed.
-
-In the end we should have gone from `TextLine` to `PlainText, Bold, PlainText , Italic, Plaintext`.
-
-Here's the result.
-
-Some **bold** text and then some _cursive_ text
-
-Next up is stage 3 processing which will affect elements depending on their position in the list of elements.