cseas · cseas · Dec 21, 2024 · Mar 26, 2023 · Mar 26, 2023 · Mar 26, 2023
diff --git a/README.md b/README.md
@@ -14,6 +14,7 @@ Code for my personal blog, hosted at [blog.absingh.com][1].
 - [ ] Add CI build and test checks
 - [ ] Add dependabot
 - [ ] use Inter variable font from @next/font
+- [ ] dig command, post: powershell-ip
 
 ### Runtime software versions
 

diff --git a/app/page.tsx b/app/page.tsx
@@ -1,5 +1,7 @@
-import { Home, config, getSortedPostsData } from "../src";
-import { pageMeta } from "../src/Home/meta";
+import { Home } from "../src/Home/Home.js";
+import { pageMeta } from "../src/Home/meta.js";
+import { config } from "../src/config.js";
+import { getSortedPostsData } from "../src/lib/posts.js";
 
 import type { Metadata } from "next";
 

diff --git a/docs/learn/dotnet.md b/docs/learn/dotnet.md
@@ -1,11 +1,14 @@
 ---
 title: ".NET"
-date: "2021-04-25"
+date: "2024-12-22"
 ---
 
-SOLID principles
+.NET is a software development framework that can be used to build cross-platform applications.
 
-Logging
-https://docs.microsoft.com/en-gb/learn/modules/aspnet-logging/
+- Start by getting familiar with the C# programming language.
+- Learn SOLID principles to understand commonly used best practices.
+- [Microsoft Docs: Logging in ASP.NET][1]
+- [Create a web API with ASP.NET Core controllers][2]
 
-https://docs.microsoft.com/en-gb/learn/modules/build-web-api-aspnet-core/
+[1]: https://docs.microsoft.com/en-gb/learn/modules/aspnet-logging/
+[2]: https://docs.microsoft.com/en-gb/learn/modules/build-web-api-aspnet-core/
diff --git a/docs/posts/array-reduce.md b/docs/posts/array-reduce.md
@@ -1,6 +1,7 @@
 ---
 title: "How to use Array.reduce() in TypeScript"
-date: "2021-04-27"
+date: "2024-12-22"
+cover: "/covers/typescript.avif"
 ---
 
 I recently bumped into a use case where I had an array of objects, similar to the one below:
@@ -13,7 +14,7 @@ const dataArray: Data[] = [
 ];
 ```
 
-The problem is to get all the index positions of the array where a key is equal to a particular value. For example, we'd like to get all the indexes where the key `a` is `true`.
+The requirement is to get all the index positions of the array where a key is equal to a particular value. For example, we'd like to get all the indexes where the key `a` is `true`.
 
 This can be done in TypeScript with `Array.prototype.reduce()` as follows:
 
@@ -45,13 +46,13 @@ The _reducer_ function passed as the first parameter above uses 3 parameters:
 
 Here's how the reducer function used in the example works:
 
-- The initial value of the accumulator is initialized to an emppty array. The accumulator is the value which will eventually contain our result at the end of the processing.
+- The initial value of the accumulator is initialized to an empty array. The accumulator is the value which will eventually contain our result at the end of the processing.
 - For every element in the array, we check if the element has a key "a" that is true. If yes, we push the index of that element in the accumulator array and return the resulting array for use in the iteration for the next element until we're done walking through the whole original `data` array.
 - Finally, the accumulator will contain the list of all the indexes that satisfy the given condition, which is value ultimately returned from our custom `getIndexes()` function.
 
-Have questions? [Discuss on Twitter][1]
+> Have questions? [Discuss on Twitter][1]
 
-_References_:
+### References
 
 - [MDN Web Docs: Array.prototype.reduce()][2]
 

diff --git a/docs/posts/check-package.md b/docs/posts/check-package.md
@@ -1,10 +1,16 @@
 ---
-title: "Linting npm packages"
-date: "2023-02-23"
+title: "[WIP] Linting npm packages"
+date: "2023-03-30"
 ---
 
-Lint npm packages using these sites:
+Publishing an npm package is a very different experience from writing locally shared code and can come with a lot of daunting challenges. Thankfully, there are multiple tools out there today that help us validate our published package.
 
-- https://publint.dev/
-- https://arethetypeswrong.github.io/
-- https://bundlephobia.com/
+1. [Publint][1]: This will help identify any errors in the format of your published package, including checking that your package.json metadata is correct and the published files and entrypoints are in a format that will work for various consumers.
+
+2. [Are The Types Wrong][2]: Shipping types with an npm package has become a common requirement as the JavaScript ecosystem has reached wide adoption of TypeScript. This tool by the TypeScript team helps us identify how different moduleResolution settings in the consumer projects will resolve the types from our package and whether any of them might break.
+
+3. [BundlePhobia][3]: Bundle size is often one of the primary concerns of a developer while choosing between two npm packages. This tool helps us analyze the bundle size of our shipped npm package.
+
+[1]: https://publint.dev/
+[2]: https://arethetypeswrong.github.io/
+[3]: https://bundlephobia.com/
diff --git a/docs/posts/git-commands.md b/docs/posts/git-commands.md
@@ -1,9 +1,9 @@
 ---
 title: "Git commands I use regularly as a Software Engineer"
-date: "2021-05-01"
+date: "2023-03-26"
 ---
 
-There are possibly thousands of "Git cheatsheets" floating all over the internet. Those have never worked for me since you never really need to remember 50 different commands to get everyday work done.
+There are possibly thousands of "Git cheatsheets" floating all over the internet. Those have never worked for me since you never need to remember 50 different commands to get everyday work done.
 
 Here are git commands I use regularly in my daily work.
 
@@ -13,53 +13,43 @@ Here are git commands I use regularly in my daily work.
    git status
    ```
 
-2. Update master branch (or the branch you want to create a feature branch from)
+2. Update main branch (or the branch you want to create a feature branch from)
 
    ```bash
-   git checkout master
+   git checkout main
    git fetch origin
-   git reset --hard origin/master
+   git reset --hard origin/main
    ```
 
-3. Create new feature branch from current branch
+3. Create new feature branch from `develop` branch
 
    ```bash
    git checkout develop
-   git checkout -b feature/new-feature
-   ```
-
-   If you want to specify which branch should the new branch be based on, add it as the last parameter.
-
-   ```bash
-   git checkout -b new-feature master
+   git checkout -b feat/new-feature
    ```
 
-   To get a new branch from a remote source, specify the remote as well.
-
-   ```bash
-   git checkout -b new-feature origin/new-feature
-   ```
+   > A popular convention is to use slash as a separator in branch names as shown above but this can sometimes [cause problems][5] in your DevOps pipelines when branch names are used to tag Docker images. For this reason, I'd recommend using only hyphens in branch names, e.g., feat-new-feature.
 
 4. Push your local changes to a remote branch
 
-   Stage
+   Stage your changes:
 
    ```bash
    git add --all
    ```
 
    > I personally like using the VSCode Git UI to preview changes and stage files one by one instead of using the above command. But if you're sure you want to push all your changes, then above command is useful to stage everything instantly.
 
-   Commit
+   Commit to local git:
 
    ```bash
-     git commit -m "Add new-feature"
+   git commit -m "feat: add new-feature"
    ```
 
-   Push
+   Push to remote repository:
 
    ```bash
-   git push -u origin new-feature
+   git push -u origin feat/new-feature
    ```
 
    > Above push command is needed only once. This is used to create a new branch in the origin remote repository and link it to your local one. Afterwards, you can use `git push` without any parameters.
@@ -118,8 +108,10 @@ Here are git commands I use regularly in my daily work.
 
 9. Resolve merge conflicts in a Pull Request
 
+   Assuming you're trying to merge `feat/new-feature` branch into `develop`:
+
    ```bash
-   git checkout feature/new-feature
+   git checkout feat/new-feature
    git pull origin develop
    ```
 
@@ -128,7 +120,7 @@ Here are git commands I use regularly in my daily work.
    ```bash
    git add .
    git commit -m "Resolve PR #12 merge conflicts"
-   git push origin feature/new-feature
+   git push origin feat/new-feature
    ```
 
    > If you're comfortable with the concept of rebase, prefer that way instead as shown in point 6 above.
@@ -140,6 +132,8 @@ Here are git commands I use regularly in my daily work.
     git push -f remote-name branch-name
     ```
 
+    > This will be useful when someone accidentally pushes a commit to a branch they weren't supposed to.
+
 11. Undo last commit. This will effectively reverse the last `git commit` and you won't lose the new changes you made.
 
     ```bash
@@ -160,7 +154,7 @@ Here are git commands I use regularly in my daily work.
    - [Feature Branch Workflow][3] when working individually and rapidly pushing new features to production.
    - [Forking Workflow][4] when contributing to open-source.
 
-2. Enforce a branch policy for your `master`/`main` & `develop` branches that allows only squash merges. Regular and Rebase merges work fine when everyone in the team knows how to correctly write a git history but more often than not people are just trying to get their code merged one way or the other. A squash merge strategy is one that stays out of your way the most and creates the least problems in a team of developers with varying expertise levels.
+2. Enforce a branch policy for your `main` & `develop` branches that allows only squash merges. Regular and Rebase merges work fine when everyone in the team knows how to correctly write a git history but more often than not people are just trying to get their code merged one way or the other. A squash merge strategy is the one that creates the least problems in a team of developers with varying expertise levels.
 
 3. Always make changes in feature branches. Never directly commit to the project's primary branches used for releases and user acceptance tests.
 
@@ -170,3 +164,4 @@ Have questions? [Discuss on Twitter][1]
 [2]: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
 [3]: https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
 [4]: https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
+[5]: https://community.atlassian.com/t5/Bitbucket-questions/How-to-push-docker-image-tagged-after-git-branch/qaq-p/1548825
diff --git a/docs/posts/nodejs-ubuntu.md b/docs/posts/nodejs-ubuntu.md
@@ -1,12 +1,19 @@
 ---
-title: "Don't install NodeJS from snap store on Ubuntu"
-date: "2021-07-30"
+title: "Don't install NodeJS from Snap Store on Ubuntu"
+date: "2023-03-26"
 ---
 
-Don't install Ubuntu from snap store
+[Snap Store][4] is usually the easiest way of installing software on Ubuntu and the closest option available for someone looking for a [brew][1] alternative for Linux.
 
-If you do, none of the npx commands will work
-https://github.com/admc/wd/issues/586#issuecomment-541583962
+However, the Snap Store distribution of Node is one we need to be cautious about as it can lead to a multitude of issues.
 
-Easiest way is to install from nodesource LTS
-https://github.com/nodesource/distributions#installation-instructions
+For example, [none of the npx commands will work][2]. This is because the Snap Store distribution of Node doesn't have the necessary permissions to install npm packages globally.
+
+The recommended way to install Node for Ubuntu users is to use a nodesource LTS distribution instead:
+
+[https://github.com/nodesource/distributions#installation-instructions][3]
+
+[1]: https://brew.sh/
+[2]: https://github.com/admc/wd/issues/586#issuecomment-541583962
+[3]: https://github.com/nodesource/distributions#installation-instructions
+[4]: https://snapcraft.io/store
diff --git a/docs/posts/npm-library.md b/docs/posts/npm-library.md
@@ -1,28 +1,69 @@
 ---
 title: "How to bundle a component library for NPM distribution"
-date: "2021-07-31"
+date: "2024-12-22"
 ---
 
-huge:
+> Pre-read: [What is Tree Shaking?][5]
 
-- webpack (output type module, required for tree shaking is not stable: https://webpack.js.org/configuration/output/#type-module)
-- rollup (ideal for libraries that don't have individual modules inside)
+With the [state of the JavaScript ecosystem][1], it can be a daunting task to publish a library. Let's look at the various options available today.
 
-0 config:
+The bundlers available for packaging your library largely fall under one of 2 categories:
 
-- parcel
-  (missing docs: https://v2.parceljs.org/getting-started/library/)
-  (has bug with re-exports: https://github.com/parcel-bundler/parcel/issues/5655)
-  (doesn't support type checking: https://github.com/parcel-bundler/parcel/issues/4022)
-- microbundle (doesn't allow rollup config, needed for preserveModules: https://github.com/developit/microbundle/issues/655)
-- tsdx (preserveModules can be hacked, but not officially supported: https://github.com/formium/tsdx/issues/276)
+1. **Full fledged bundler:**
 
-bundlers toolip report
-https://bundlers.tooling.report/
+   These consist of bundlers like Webpack and Rollup. These give you maximum flexibiltiy and control over your build process and output, with a huge community for support and a large number of plugins available.
 
-Comparison of bundlers
-https://bundlers.tooling.report/transformations/dead-code/
+   The caveat with these is that it can take a lot of time to get the right setup with these, specially for beginners, and the elaborate config needed to set up a build can be overwhelming to understand.
 
-https://blog.theodo.com/2021/04/library-tree-shaking/
+2. **Zero-config bundler:**
 
-https://developers.google.com/web/fundamentals/performance/optimizing-javascript/tree-shaking
+   These bundlers are often an abstraction layer on top of existing tools in the ecosystem and promise to hide away the complexity of full fledged bundlers.
+
+   Some popular options are:
+
+   - Parcel
+   - Microbundle
+   - Tsdx
+   - Tsup
+
+   While these provide a great default config that would work for most libraries, the limited amount of config options can become a hurdle as you move on to advanced requirements for your bundling pipeline.
+
+## Webpack
+
+While webpack is arguably the most popular build tool for web applications, it falls short in features required for building libraries. Specifically, output type `"module"`, that is required to enable tree shaking for your library consumers, is [not stable yet][2].
+
+## Rollup
+
+Rollup is ideal for publishing libraries and provides maximum configurability. The `preserveModules` option is often used by library authors to package their library in a format best suited for consumption by the bundler of the consumer application. However, keep in mind that this option applies tree shaking to the library build output so it's recommended to [designate all files explicitly as entry points][3] instead.
+
+## Parcel
+
+Parcel is a zero-config bundler that has documented support to [improve tree-shaking][4] for your library's consumers.
+However, there are some open bugs that could be a deal breaker for you:
+
+- Bug with re-exports: [https://github.com/parcel-bundler/parcel/issues/5655](https://github.com/parcel-bundler/parcel/issues/5655)
+- Doesn't support type checking: [https://github.com/parcel-bundler/parcel/issues/4022](https://github.com/parcel-bundler/parcel/issues/4022)
+
+## Microbundle
+
+Microbundle is yet another zero-config bundler that promises to simplify the library publishing process. It is built on top of Rollup.
+
+However, it doesn't support customising any Rollup options which you might need for improving tree shaking for your library consumers, specially when you're building something with multiple isolated exports e.g. a component library.
+
+## Tsdx
+
+Tsdx is a popular zero-config CLI for TypeScript package development. However, it's not maintained anymore and is not recommended for use. Rollup's preserveModules is also not officially supported: [https://github.com/formium/tsdx/issues/276](https://github.com/formium/tsdx/issues/276).
+
+> Have questions? [Discuss on Twitter](https://x.com/cse_as)
+
+### References
+
+- Bundlers tooling report: [https://bundlers.tooling.report/](https://bundlers.tooling.report/)
+- Comparison of bundlers: [https://bundlers.tooling.report/transformations/dead-code/](https://bundlers.tooling.report/transformations/dead-code/)
+- [How To Make Tree Shakeable Libraries](https://blog.theodo.com/2021/04/library-tree-shaking/)
+
+[1]: https://x.com/acemarke/status/1443650054187847681
+[2]: https://webpack.js.org/configuration/output/#type-module
+[3]: https://rollupjs.org/configuration-options/#output-preservemodules
+[4]: https://parceljs.org/getting-started/library/#improving-tree-shaking
+[5]: https://developers.google.com/web/fundamentals/performance/optimizing-javascript/tree-shaking
diff --git a/docs/posts/tree-shaking.md b/docs/posts/tree-shaking.md
@@ -1,6 +1,6 @@
 ---
-title: "Why should NPM library authors care about Tree Shaking"
-date: "2021-07-29"
+title: "[WIP] Why should NPM library authors care about Tree Shaking"
+date: "2023-03-26"
 ---
 
 Flat files are an issue for webpack:

diff --git a/docs/posts/zshell-colors.md b/docs/posts/zshell-colors.md
@@ -1,6 +1,6 @@
 ---
-title: "Make MacOS Terminal prompt look colorful like Ubuntu"
-date: "2021-08-16"
+title: "[WIP] Make MacOS Terminal prompt look colorful like Ubuntu"
+date: "2023-03-30"
 ---
 
 Switching from Ubuntu's colorful bash terminal to the bland monochrome z-shell of MacOS can be underwhelming. All that white makes it hard to distinguish one command run from the other one when you're firing dozens of commands in a day.

diff --git a/pages/_document.tsx b/pages/_document.tsx
@@ -1,6 +1,6 @@
 import Document, { Head, Html, Main, NextScript } from "next/document";
 
-import { config } from "../src";
+import { config } from "../src/config.js";
 
 export default class MyDocument extends Document {
   render() {

diff --git a/pages/learn/[id].tsx b/pages/learn/[id].tsx
@@ -1,7 +1,7 @@
 import { GetStaticPaths, GetStaticProps } from "next";
-import { getAllLearnIds, getLearnData } from "../../src/lib";
+import { getAllLearnIds, getLearnData } from "../../src/lib/learn.js";
 
-export { LearnPage as default } from "../../src";
+export { LearnContent as default } from "../../src/LearnContent/LearnContent.js";
 
 export const getStaticPaths: GetStaticPaths = async () => {
   const paths = getAllLearnIds();

diff --git a/pages/learn/index.tsx b/pages/learn/index.tsx
@@ -1,7 +1,7 @@
 import { GetStaticProps } from "next";
-import { getSortedLearnData } from "../../src/lib";
+import { getSortedLearnData } from "../../src/lib/learn.js";
 
-export { Learn as default } from "../../src";
+export { Learn as default } from "../../src/Learn/Learn.js";
 
 export const getStaticProps: GetStaticProps = async () => {
   const allLearnData = getSortedLearnData();

diff --git a/pages/posts/[id].tsx b/pages/posts/[id].tsx
@@ -1,7 +1,7 @@
 import { GetStaticPaths, GetStaticProps } from "next";
-import { getAllPostIds, getPostData } from "../../src";
+import { getAllPostIds, getPostData } from "../../src/lib/posts.js";
 
-export { PostContent as default } from "../../src";
+export { PostContent as default } from "../../src/PostContent/PostContent.js";
 
 export const getStaticPaths: GetStaticPaths = async () => {
   const paths = getAllPostIds();

diff --git a/pages/posts/index.tsx b/pages/posts/index.tsx
@@ -1,7 +1,7 @@
 import { GetStaticProps } from "next";
-import { getSortedPostsData } from "../../src";
+import { getSortedPostsData } from "../../src/lib/posts.js";
 
-export { Posts as default } from "../../src";
+export { Posts as default } from "../../src/Posts/Posts.js";
 
 export const getStaticProps: GetStaticProps = async () => {
   const allPostsData = getSortedPostsData();

diff --git a/public/covers/typescript.avif b/public/covers/typescript.avif