Added a post on tcr with typescript

Author: marcusoftnet

_posts/2019-01-11-trying-out-test-commit-or-revert.md

@@ -11,6 +11,8 @@ tags:
 
 I stumbled over a new concept the other day. As it was conceived by Kent Beck, that inspired and thought me a lot in the past, I got interesting.
 
+I have [updated this to modern tools here](2025-10-29-trying-out-test-commit-or-revert-modern.md)
+
 **[UPDATED]**
 
 I read Kent's blog post a bit too fast and missed that this idea was actually proposed by [Oddmund Strømmer](https://twitter.com/jraregris). Very sorry that I missed that in my writeup, Oddmund. Thanks for correcting me, [Raquel](https://rachelcarmena.github.io/2018/11/13/test-driven-programming-workflows.html).
@@ -48,14 +50,10 @@ You can find [my code here](https://github.com/marcusoftnet/fizzbuzz-tcr)
 Here are the commands I ran to get started:
 
 1. `mkdir fizzbuzz-tcr && cd fizzbuzz-tcr` to create the directory and jump into it
-
-2. `npm init -y` to create an empty `package.json` file
-
-3. `npm I -D mocha chai standard` to install the tools I need
-
-4. `touch index.js index.test.js` to setup the two files we will work in
-
-5. I wrote scripts for test, lint and pretest
+1. `npm init -y` to create an empty `package.json` file
+1. `npm i -D mocha chai standard` to install the tools I need
+1. `touch index.js index.test.js` to setup the two files we will work in
+1. I wrote scripts for test, lint and pretest
 
    ```json
    "scripts": {
@@ -66,10 +64,9 @@ Here are the commands I ran to get started:
    ```
 
    1. I'm linting my code with [standard js](https://standardjs.com/)
-   2. The testing is done using [mocha](https://mochajs.org/)
-   3. And the `pretest` script is automatically running the linting before the tests are executed
-
-6. I then wrote the first test to check that my infrastructure worked. In the `index.text.js`:
+   1. The testing is done using [mocha](https://mochajs.org/)
+   1. And the `pretest` script is automatically running the linting before the tests are executed
+1. I then wrote the first test to check that my infrastructure worked. In the `index.text.js`:
 
    ```javascript
    /* global describe, it */
@@ -82,11 +79,9 @@ Here are the commands I ran to get started:
    });
    ```
 
-7. By running `npm t` I linted and ran the first test
-
-8. I created a `.gitignore` from the excellent <https://www.gitignore.io/> using `npx gitignore node`
-
-9. Finally, I initialized git and made a first commit `git init` initial commit
+1. By running `npm t` I linted and ran the first test
+1. I created a `.gitignore` from the excellent <https://www.gitignore.io/> using `npx gitignore node`
+1. Finally, I initialized git and made a first commit `git init` initial commit
 
 ## Setting up TCR workflow in package.json
 

_posts/2019-08-24-scraping-functionally---to-save-my-inheritance.md

@@ -59,8 +59,8 @@ mkdir abbesaysscraper && cd abbesaysscraper
 npm init -y
 npx gitignore node
 git init .
-npm I axios cheerio
-npm I -D standard
+npm i axios cheerio
+npm i -D standard
 touch index.js
 ```
 

_posts/2021-06-17-introducing-scradd---the-script-adder.md

@@ -20,7 +20,7 @@ Let’s say that you are writing a tutorial on how to test next apps. You want t
 npx create-next-app demo
 cd demo
 npx scradd . test "mocha . -R dot -w"
-npm I -D mocha
+npm i -D mocha
 ```
 
 I don't expect this tool to be widely used and spread but I was pretty fun to write it - the testing was particularly tricky to get working.

_posts/2022-11-17-nextjs---testing-async-react-components.md

@@ -165,7 +165,7 @@ But, as I wrote in the beginning, this is nothing that Next package up for us.
 In order make this happen there are a few things we need to install and configure. Run these commands and I'll describe what happened below:
 
 ```bash
-npm I -D @testing-library/react jest @testing-library/jest-dom ts-node jest-environment-jsdom
+npm i -D @testing-library/react jest @testing-library/jest-dom ts-node jest-environment-jsdom
 
 npx -y scradd . "test" "jest"
 npx -y scradd . "test:watch" "npm t -- --watch"
@@ -295,7 +295,7 @@ We now have two, quite similar, options. We can supply a _real_ fetch for the `j
 Run this:
 
 ```bash
-npm I -D jest-fetch-mock
+npm i -D jest-fetch-mock
 ```
 
 That is a tool that makes mocking of `fetch` easy. Update the test to this:
@@ -343,7 +343,7 @@ Ok - lots of code here, but it's mainly just me setting up the fake data `luke`
 
 Other than that - it now works and we can test our `async` server component using a fake `fetch`.
 
-Oh - you could use a _real_ fetch too, I presume., if you wanted, by supplying your component a real implementation, like [`node-fetch`](https://www.npmjs.com/package/node-fetch) (install with `npm I -D node-fetch`).
+Oh - you could use a _real_ fetch too, I presume., if you wanted, by supplying your component a real implementation, like [`node-fetch`](https://www.npmjs.com/package/node-fetch) (install with `npm i -D node-fetch`).
 
 I haven't played around with this, since I'm not a fan of having my unit and integration tests depend on APIs. That's what end-to-end tests are for. But I'm quite sure you could make this work.