Forem: colin-williams-dev

How to Reclaim Memory from Docker WSL

colin-williams-dev — Tue, 09 Dec 2025 08:05:20 +0000

If you've ever had the misfortune of working with Docker on a Windows machine you are in the right place.

Also, if you've arrived here via a google search on "how to get memory back from #!$@%^ing DOCKER" here is the cheat sheet so you can be on your merry way 🎅

# documentation: https://learn.microsoft.com/en-us/windows/wsl/wsl-config#wslconfig
# actual contents of .wslconfig @ %UserProfile%
[wsl2]
processors=10
memory=2123366400
swap=1073741824
[experimental]
autoMemoryReclaim=gradual

# the WSL documentation suggests finding the GUI and configuring there:
# Start > WSL Settings

# the default is half of your RAM (reduce this further)
# I think the default is all of the processors (e.g. 20) (I reduced this to 10 or 5)

# comprehensive blog with example .wslconfig
# https://www.valens.dev/blog/Take-control-of-your-WSL-resources-for-smooth-development

Now for my thoughts...

Warning!

This blog is going to piss a lot of people off because...

Everyone LOVES Docker (I don't)
I curse a lot in this blog... (It's censored)

Docker is an @$#hole on Windows🙂

As a native Windows developer who works almost exclusively in the Microsoft tech stack (TypeScript, C#/.NET, MS SQL Server, Azure) I have no reason to go near Windows Subsystem for Linux... that is... until Docker enters the picture... 🙄

I have worked with Docker for two years (feels like devs don't often get a choice in the matter) and only last week did I discover the existence (the necessity...) of the .wslconfig file.

For some reason, WSL2 comes ready to steal massive amounts of your machine's processing power out of the box. Docker on Windows "requires" WSL for its backend (presumably for the container/VM orchestration). The defaults for what your VMs can partition from your hardware are as follows:

100% of your CPU cores
50% of your RAM
n% of your hard disk

This feels problematic in general but allow me the pleasure of listing explicit reasons why: (why you might want to relegate only the bare minimum processes to your WSL VMs and keep the vast majority of your processing power on the Windows partition)

You want access to a desktop GUI and native apps*
You want access to your primary file system
You want to limit the amount of latency you have to deal with
You work in enterprise which runs anti-malware and other spyware on your machine which will also hog resources...

*Yes, I know, WSLG exists and is actually goated...

TL;DR - You want to preserve as much processing power as possible on your primary partition for a litany of valid reasons.

So, why does WSL think you want to surrender ONE-HUNDRED-PERCENT OF YOUR CPU CORES AND FIFTY PERCENT OF YOUR RAM??? 🤔🤔🤔

Idk...

But anyway, here is how to fix it: Bottleneck Hardware Thresholds in the wslconfig File.

Step 1 - Create a `.wslconfig` File

The official Microsoft Documentation strongly suggests you do this through the Windows UI so I'll list those steps.

(see the top "cheatsheet" if you want to raw-dog it and just cd ~ (your %USERPROFILE% most likely) ni .wslconfig etc etc etc)
Legend: Blah Blah Setting: My - Choice (suggested percent hardware capacity)

Navigate to: Start > WSL Settings

Step 2 - Bottleneck Memory and Processor

Adjust settings in "Memory and processor"
- Processor Count: 10 - 15 (50-75%)
- Memory Size: 2000MB - 8000MB (6.25% - 25%)
- (2000MB is the minimum for SQL Server)
- Swap Size: 1024MB (0.002%+)

Step 3 - Reclaim Memory During Runtime

By default, Windows will only reclaim memory from the partitions automatically on cache drop, but with an experimental feature we can reclaim unused resources while the VMs are running.

Adjust settings in "Optional Features"

Auto memory reclaim: Gradual

Step 4 - Restart WSL

Either close Docker Desktop or whatever or run the following commands

# see if WSL is running anything
wsl --list --running
# if it is, teriminate it
wsl --shutdown

Congratulations! 🎉🎈You just reclaimed tons of processing power that Docker and WSL stole without your permission!🥳

Addendum

This config will apply thresholds/bottlenecks to the entire WSL orchestrator, meaning, if you need more resources than a single SQL Server Instance and some Functions, these ratios will not work for you.
"Swap Size" creates a file on disk which will use native I/O computational processing power for the spills when your VM needs to exceed the RAM/memory bottleneck. This can have adverse effects on the health of your physical disk. DO NOT USE SWAP SIZE/FILE IF YOU HAVE AN HDD (each HDD has a finite number of READS/WRITES in its lifetime)

#docker #wsl #vm #local #performance #bottleneck #ram #memory #cpu #disk

What is the git index?

colin-williams-dev — Mon, 27 May 2024 19:57:30 +0000

🗃 💻 🌊

Ever so often, I like to "plunge" (more on that later..) into the depths of Git deeper to strengthen my understanding of this tool I leverage every single day.

Recently, I wanted to untrack files that had previously been tracked and ultimately were pushed to my remote repository.

I added the directory for said files to my .gitignore and believed my next step would be to just delete them off the remote directly on GitHub... But, it occurred to me there were probably better ways to achieve this same outcome.

(scroll down to the📌for tl;dr)

My investigating lead me to a few places:

1. Super-User Forum Comment on --cached

Here is where I learned about git rm --cached....
What --cached does is:

"Use this option to unstage and remove paths only from the INDEX. Working tree files, whether modified or not, will be left alone."
[emphasis mine] [source below]

2. Git Documentation on git rm

This lead me further into this "pipe" (more still to come...) with asking myself "what is the git index?"

3. SO forum comment on the actual /.git/index

Where I learned that:

"The index is a single, large, binary file in /.git/index, which lists all files in the current branch, their sha1 checksums, time stamps and the file name -- it is not another directory with a copy of files in it."

Moreover, the git "index" is where your changes go when you run git add ... and directly into that above mentioned binary (/.git/index) which acts as your "staging area" in between your workspace (working directory) and your local repository (where your changes go to your current branch when you run git commit ...).

📌

To summarize, when you run git rm --cached folder/\* git will delete the (history?) data represented by this directory in your /.git/index binary/staging area. Next, you push these changes to your remote to have them scrubbed out, LEAVING your directory locally. If this directory has been added to your .gitignore, it will no longer be tracked as well.

🚽 🌊 🏄‍♂️

Now for the conceit that git uses regarding the words "plunge", "pipe" and these 🌊 emojis I've been cheekily trying to breadcrumb into this post...

Through my investigation I learned of the "high level" and "low level" conceit that git adopts: "Porcelain" (high) and "Plumbing" (low).

4.a. high_level_commands_porcelain

4.b. low_level_commands_plumbing

Anyway, just thought that was funny. Git uses a toilet metaphor in their documentation... 😋

Honorable mention: Think like (a) Git: LSD & Chainsaws

Building a Simple Production Error-Logger w/ Node and S3

colin-williams-dev — Sun, 14 Apr 2024 05:48:09 +0000

🤔Problem:

You want to record error logs asynchronously for an app in production, but you don't want to eat up limited disk space. You also want your dev team to easily be able to access the logs as soon as they can. You also don't want to pay for things you don't have to...😋🏴

💡Solution:

Hook into the processes you are already listening for and logging to stderr/stdout but also write them to a file which you can then ship to a hosted service and delete the logs from disk.

There were a few things I wanted my logger to satisfy:

Catch and log errors that have not been handled in the code.

Persist the logs so that the dev team has time to find them (the app should not be crashing or terminating).

Don't take up precious disk-space on the deployment.

Render the data in a human readable format with useful information.

Make the data as available as possible (without being completely public*).

*AWS IAM users pending still..

📌Node.js Process and FS

I was working on my application's execution context architecture, setting up lots of try/catches with re-throws when the above "💡Solution" thought occurred to me. I had just written my top level:

/////////////////////////////////////////////////////////
///// #region top-level node critical-failure catch /////
process.on('uncaughtExceptionMonitor', (err, origin) => {
  console.error(`Critical failure, propagated to top-level from ${origin}, error: `, err);
  /* TODO: create custom monitor class here that will handle application recover or restart from unhandled critical failure... */
});

process.on('unhandledRejection', (reason, promise) => {
  console.log('Unhandled Rejection at:', promise, 'reason:', reason);
  /* TODO: application logging, throwing an error, or other logic here for uncaught promises */
});

process.on('uncaughtException', (err, origin) => {
  const log = `Caught exception: ${err}\n` +
  `Exception origin: ${origin}\n`;
  console.error("Critical Error -- app is about to explode... \n performing synchronous cleanup.. \n writing crash state to terminal..");
  fs.writeSync(
    process.stderr.fd,
    log
  );
  /* TODO: needs to be pruned on CRON job, otherwise infinitely expands for logs */
  if (process.env.NODE_ENV === "production") {
    fs.appendFileSync(
      "error.log",
      `Logging to ./error.log app critical failure:\n
      ${new Date().toISOString()}\n
      ${log}\n --- \n
      \n`
    );
  }
  console.error("goodbye.");
});
/////////////////////////////////////////////////////////
// #endregion ///////////////////////////////////////////

With this implementation I was writing to a file in the root called "error.log" (creating--if not exists--to the local disk).

With a node backend, I could log what I needed (on node's processes events) in the typical stderr/stdout but I also wanted to make it persist. I could have just stuffed it into a database somewhere... but, I didn't want to pollute the database and I also wanted the logs to be more readily available. I knew I could use node's fs module to write to a file but I was concerned about eating my production instance's disk space. 😓

I wanted to leverage more of what I already had available to me as well as limit my costs as much as possible. I thought about where else I could put these logs with low overhead while provisioning as few resources as possible. I started with technologies I already had implemented for my project:

GitHub (where the development git repo lives)
- Pages (free)❌
AWS (the EC2 where the production deployment will eventually live)
- S3 (free)✅

📌AWS S3 HTML/JS

I knew I could quickly provision an index.html and probably throw in a <script> where I could leverage the JS Fetch API to send an HTTP request to my node server. I could also easily use the dom with vanilla JS and HTML to display my logs in a nice, human-readable format:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>GH-SP-Logger</title>
</head>
<body>
  <h1>GH-Scrum-Poker-Error-Logger:</h1>
  <ol id="error-logs-list"></ol>

  <script>
    function fetchErrorLogs() {
      fetch("https://tricky-monkeys-sin.loca.lt/error-logger", { // TODO: replace with static origin-url of hosted node web-server
        method: "GET",
        mode: "cors",
        headers: {
          "Accept": "text/plain",
          "bypass-tunnel-reminder": "true" // Set the bypass-tunnel-reminder header TODO: remove this
        }
      })
        .then(response => response.text())
        .then(data => {
          const logs = data.split("---");
          logs.forEach(log => {
            console.log(`Next Log Entry -- ${log}`);
            const errorLogsElement = document.getElementById("error-logs-list");
            const li = document.createElement("li");
            const pre = document.createElement("pre");
            const space = document.createElement("p");
            pre.textContent = log;
            space.textContent = "---";
            li.appendChild(pre);
            li.appendChild(space);
            errorLogsElement.appendChild(li);
          });
        })
        .catch(err => console.error(err));
    };

    fetchErrorLogs();

    setInterval(fetchErrorLogs, 720 * 60 * 1000); // fires every 12 hours TODO: set this to something?

    /* Set interval to purge <li> items from <ol> every 2 weeks */
    setInterval(() => {
      const errorLogsElement = document.getElementById("error-logs-list");
      errorLogsElement.innerHTML = ""; // Clear all <li> items
    }, 14 * 24 * 60 * 60 * 1000);
  </script>
</body>
</html>

I utilized JS native setInterval to constrain how frequently the requests were being sent (once every 12 hours) and purge stale error logs (once every two weeks). I opted for a long time between purges since the ordered list HTML element will keep the sequence of logs relevant to their time of occurrence (and I also have an ISO string Date prepended to each item). The free hosting space for a static site with S3 should suffice and this way I don't need to leverage any object delete operations which could incur extra costs.

This seemed all fine and dandy... but while setting up the static site on S3 I noticed something... CORS... (ughhhh)

I threw up a wild card policy (S3) in json for testing/development:

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "HEAD"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": [],
        "MaxAgeSeconds": 3000
    }
]

As soon as the webserver is deployed (dev and test on localhost for now) the allowed origins will be swapped out.

📌Tunneling/Proxy:

During this process it occurred to me that the deployed S3 would not be able to communicate with my locally running node server... I had used tunneling before with ngrok but I wanted something lighter and simpler... enter localtunnel. With a simple CLI command: lt --port 3000 I could tunnel my locally-running-node-process port a randomly generated, live HTTPS URL.

You may have already noticed this URL in the S3 fetch call: fetch("https://tricky-monkeys-sin.loca.lt/error-logger" ...). This, as well as all wildcard origin-access will all be swapped out for the safeguarded origin of the production server.

📌Node Endpoint and Middleware

Next, I had to set up an endpoint that would receive the request from my S3's JS Fetch request. I knew I could read the data (the logs) from the file on disk and send them somewhere over HTTP with node by creating an endpoint and simple middleware.

First, I designed the middleware function:

const pathToFile = path.resolve(__dirname, "..", "..", "error.log");

/* TODO: This reads from local error.log on disk... needs to be pruned incrementally? */
const errorLogger = async (_: Request, res: Response): Promise<void> => {
  try {
    console.log(`Reading from Error Log file on Disk.. -- ${pathToFile}`);
    fs.readFile(pathToFile, "utf-8", (err, data) => {
      if (err) {
        console.error(`404 root error.log could not be read.. ${err}`)
        res.sendStatus(404);
      }
      res.setHeader("Access-Control-Allow-Origin", "*"); /* TODO: SWAP OUT THIS "*" WITH ACTUAL ORIGIN (replace lt proxy) */
      res.send(data); /* TODO: swap out origin in S3 permissions: CORS when static origin created (when above swap happens) (also noted in src/index) */
    });
  } catch (error) {
    console.error(`500 Failure reading error.log from disk.. ${error}`);
    res.sendStatus(500);
  }
};

and hooked it up to an endpoint:

export const configureServer = (server: Application) => {
    /* Global Middleware */
    server
        .use(middleware)
        .use(cors())
        .use(json())
        .use(urlencoded({ extended: true }));

    server.get("/error-logger", errorLogger);
// ...

📌CRON

The last step was to ensure that disk space was not being eaten up by the node FS write operations in the "production" environment. I elected to purge the file on disk, once a day, since it would be sending all log data every 12 hours to the S3 bucket. To achieve this I implemented a simple CRON Job:

// Path to the local error log file defined earlier
const pathToFile = path.resolve(__dirname, "..", "..", "error.log");

// Define a cron job that runs every day at midnight
const job = new cron.CronJob("0 0 0 * * *", () => {

  // Truncate the error log file to empty it
  fs.truncate(pathToFile, 0, (err) => {
    if (err) {
      console.error("Error truncating error.log file:", err);
    } else {
      console.log("Disk error.log file has been cleaned out.");
    }
  });
});

// Start the cron job
job.start();

Hopefully you found this interesting and/or informative! Leave a comment if you have any suggestions 😋

P.S.

Depending on the success of this application I may migrate to a paid service such as Sentry.io for a much more elegant error monitoring process. (But, I think this workflow has a pretty decent DevX (since the team only needs to visit a URL to see a styled HTML render))

Transferring Files of Any Size with Powershell

colin-williams-dev — Fri, 08 Mar 2024 03:43:49 +0000

So, you have a directory that you want to share with your team. It's a big one. You think: "I'll compress this to a zip and email it" to avoid laborious hosting steps. You go to email your project when you are greeted with this:

😑😑😑

I got tired of seeing this so I wrote a couple Powershell scripts to break the files down into arbitrarily-sized buffers, from which we can transfer in however many emails required.

This workflow requires the SENDER and RECIPIENT to each run one of the scripts... (you'll need the directory you clone these scripts to be in your PATH if you don't want to reference them with their full paths...)

The steps are simple:

Sender - `split-file.ps1`

Sender Runs:
- split-file.ps1 -inFile "C:\path\to\your\file.zip" -buffSize 4MB
- the out files will be named "1", "2", "3", ... to the current working directory
- you can pass whatever -buffSize you need for your file (e.g. -buffSize 100KB)

Recipient - `converge-files.ps1`

Recipient Runs:
- .\converge-files.ps1 -outFile "reassembled_file.zip" -buffSize 4MB
- this will search the current working directory, matching filenames that are incrementing digits
- you should pass the same -buffSize argument as you did to split-file for best results (resembling original file)

Linked below is the repository that holds the two scripts and a helpful README with more thorough explanation. Open to cloning if you think this will be helpful for you! Feel free to make an issue or a PR if you think of ways to improve the scripts (I am a beginner with Powershell).

In case you don't want to download anything, here are the contents of the two scripts:

1. `split-file.ps1`

param(
  [string]$inFile,
  [int]$buffSize = 4MB
)

function split($inFile, [int] $buffSize){

  $stream = [System.IO.File]::OpenRead($inFile)
  $chunkNum = 1
  $barr = New-Object byte[] $buffSize

  while ($bytesRead = $stream.Read($barr, 0, $buffsize)){
    $outFile = "$chunkNum"
    $outStream = [System.IO.File]::OpenWrite($outFile)
    $outStream.Write($barr, 0, $bytesRead);
    $outStream.close();
    Write-Output "wrote chunk $outFile to file"
    $chunkNum += 1
  }
}

split @PSBoundParameters

2. `converge-files.ps1`

param(
    [string]$outFile,
    [int]$buffSize = 4MB
)

function converge($outfile, [int] $buffSize) {

  $files = Get-ChildItem | Where-Object { $_.Name -match '^\d+$' } | Sort-Object { [int]$_.Name }

  $outStream = [System.IO.File]::OpenWrite($outFile)

  foreach ($file in $files) {
      $inStream = [System.IO.File]::OpenRead($file.FullName)
      $buffer = New-Object byte[] $buffSize
      $bytesRead = $inStream.Read($buffer, 0, $buffSize)
      $outStream.Write($buffer, 0, $bytesRead)
      $inStream.Close()
  }

  $outStream.Close()
  Write-Output "Re-assembled file written to $outFile"
}

converge @PSBoundParameters

Note: "Splatting", or using the @ before the PSBoundParameters keyword will pass all the parameter arguments to the fn invocation in the script from how you invoked it in the CLI

How it works...

The split (first) script, opens a Read stream by reading the -inFile argument and breaks it into chunks of bytes. The bytes will be stored in a byte array ($barr) and will grow (Write) incrementally in chunks of bites determined by the -buffSize argument until the .Read of the stream returns zero which will terminate the while loop. The loop will output files named by the incrementing integer $chunkNum starting with 1 (which will later be captured as a digit file name in sequence).
The converge script, searches the CWD (where the split function outputs...) for filenames that are digits and sorts them numerically (to persist original order of byte chunks). It then uses a Write stream and a byte array to re-combine the chunks of bytes back into a single output file, resembling the original.

Voila! Your file is now duplicated and reconstructed. You will not even notice the difference. The purpose is the intermediary stage between the two scripts, where you can now send your data chunk files below any file transfer size limit and reconstruct them ("converge") when they arrive at their destination. 🏴🏴🏴

My public repository for cloning the scripts

Throw me a react on this blog and a star on the repo if this was helpful for you! <3

Bridge-Branch Strategy with GitHub Actions

colin-williams-dev — Mon, 05 Feb 2024 06:08:07 +0000

Problem:

As a developer, you want to merge small, file imports into your remote repository's development branch to share with your team incrementally, but, your workflow is bottlenecked by opening and closing PRs every time.

Solution:

Create a "Bridge-Branch" in parallel to main or your development branch that has Actions watching it and will automatically merge changes into main.

Here is the Bridge-Branch Template Repo with PR and Issue Templates I created to solve this problem. Feel free to Fork ( and Star 🌟😉) if you find yourself in a similar scenario.

Caveats:

Typically, Rules and Rulesets on GH exist for a reason, and it is not best practice to build ways to circumvent them. However, when you find a reasonable case to do so, you MUST ENSURE:

Small Incremental Changes (Easy to revert without loss)
Consistently syncing the source branch with the target branch to avoid conflicts
Good communication and notifications for your team, as changes will be going into your remote on a branch that other developers depend on MORE FREQUENTLY.

Thoughts:

There are other ways of handling this but this is a strategy that I developed while working on a collaborative Unity project. In our case, we wanted to be able to incrementally import Sprites into our Unity code base and check them into our remote repository so the entire team could pull them down and review them in an Editor or Image Viewer tool so that they can make accurate suggestions early in their design process.

The nature of Sprites in a Unity project are that they will sit inside a specific directory (away from any scripts/code) until they are plugged in as components to Game Objects. For this reason, upon their creation they can be merged into the development branch of our remote repo without any risk of merge conflicts (for the most part).

The "Bridge-Branch" Strategy

This may or may not exist elsewhere, and may arguably be an anti-pattern in some git workflows, but for ours I theorized and executed a strategy. I configured our repository's permissions and runner, then designed two Actions:

To watch the "Bridge-Branch" and merge changes to main automatically on push, removing the bottleneck.
To watch "Main" and ensure all the code in the "Bridge-Branch" stays in sync with it, preventing any merge conflicts during automation. Both listen for pushes and then checkout and merge the desired changes to the specified target.

🔁auto_merge_bridge_to_main.yaml 1

name: Auto Merge Bridge Branch to Main

on:
  push:
    branches:
      - your-bridge-branch

jobs:
  merge-to-main:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v4
      # this ensures all histories are fetched for runner, avoiding `unrelated histories` merge error
      with:
        fetch-depth: 0

    - name: Merge to main
      # GH actions/checkout requires git identity to be configured for security, top two commands handle that
      run: |
        git config user.name "${{ github.actor }}"
        git config user.email "${{ github.actor }}@users.noreply.github.com"

        git fetch origin
        git checkout main
        git merge --no-ff -m "auto merge bridge changes to main" ${{ github.ref }}
        git push origin main

🔁auto_sync_main_to_bridge.yaml 2

name: Auto Sync bridge-branch with main

on:
  push:
    branches:
      - main

jobs:
  sync-with-main:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v4
      # this ensures all histories are fetched for runner, avoiding `unrelated histories` merge error
      with:
        fetch-depth: 0

    - name: Merge changes into sprite-branch
      # GH actions/checkout requires git identity to be configured for security, top two commands handle that
      run: |
        git config user.name "${{ github.actor }}"
        git config user.email "${{ github.actor }}@users.noreply.github.com"
        git config pull.rebase false

        git fetch origin
        git checkout your-bridge-branch
        git pull origin main
        git merge --no-ff -m "auto sync main changes to bridge branch" main

        git push origin your-bridge-branch

The purpose of this "Bridge-Branch" is to act as an intermediary between feature development and main. When I was first drafting up how to achieve this I was thinking: "I want a connection from my local feature-branch to main like a web socket, something that stays open so I can push in changes any time" 🤔🤔🤔

And, because Unity converts Sprites to YAML if these changes go into our remote repository they would require a PR to be opened, reviewed, approved, merged and then closed. A lot of extra work and bottlenecking for a change that will have no significant impact on the code. All of the review of the actual design occurs in the Unity Editor where the Sprite can actually be viewed (as a .png or checked out inside our Team's sprite editor Aseprite as a .ase or .aseprite per our workflow for art prototypes)

How to Use:

Bootstrap a repository from my template OR create a .github/workflows directory in your project root and copy/paste the two files I list below into it.
Navigate to your projects "Settings" view on Github
Click the "Actions" dropdown-section in the left-side toolbar
Scroll to "Workflow permissions" and toggle "Read and write permissions" and "Allow GitHub Actions to create and approve pull requests"
- You may need to perform this in the "Organization Settings" level above your repository if it is inside of one to establish default permissions across the group's repositories first
Create a branch parallel to main (like a development or staging branch) (this will be your "Bridge-Branch") on the remote
Plug the name of that branch into the places where your-bridge-branch exists in the auto_merge_bridge_to_main.yaml file
Plug the name of that branch into the places where your-bridge-branch exists in the auto_sync_main_to_bridge.yaml file

Test:

Create a new feature branch
- Make a small change like a "hello world" .md, .sh or any extremely simple file
- Push it to the remote
- Merge it into main
Checkout the "Bridge-Branch" you created to ensure those new changes are reflected on this branch as well
While checked out on the "Bridge-Branch"
- Make another small change
- Push that change to the remote "Bridge-Branch"
Checkout main to ensure those changes are reflected here

You should also be able to view the Actions working here: https://github.com/your-organization?/your-repo/actions or by clicking the Actions tab on the view for your repo on GH.

How to Set up: Git and GH for Unity

colin-williams-dev — Mon, 29 Jan 2024 03:31:34 +0000

With the provided Unity .gitignore file available through GitHub you can easily collaborate with your favorite version control system (Git) and remote repositories on your game development projects. Following these easy steps you can set up a new Unity project and connect to a new remote repository on GitHub or even jump into a preexisting one quickly.

Doing this will allow you to confidently branch your development and iteratively make changes like you would through the SDLC of any other application. The Unity .gitignore preset includes all necessary files and excludes the large ones (would need Git LFS otherwise) that will be built by the Unity editor when you open the project anyway.

How to hook up Unity to Git/GH

Make a Repository on GitHub (GH)
- If you aren't using a template, make sure you select "Unity" .gitignore
Make a new project from Unity Hub (UH)
- Make the name of the project the SAME as what the cloned down repo will be(should just be the name of the repo (sans-"main"))
Create a script in your new Unity project (within Unity) to open it with VS by double clicking it
Open a terminal in the root folder in VS (your unity proj)
Run git init to initialize a git repo inside of it
Create a main branch if it isn't autogenerated from git init
Run git remote -v to see if origin has been created automatically or not...
If it HAS:
- Run git remote set-url origin https://gihub.com/your/repo.git
- to set the remote URL for origin to your clone URL for the GH repository
Perform ONE of the FOLLOWING (A or B):
A:
- Run git pull origin main
B.1: (if you have anything in your Unity git repo that you need merged with the remote repo)
- In the terminal where you ran git init (the root of your Unity project) run git checkout main (if you are not already in main)
- Run git branch -m main-holder to rename this branch temporarily
- Run git fetch
- Run git checkout main
- Run git pull origin main this will create a local main that matches the remote main and sync
- Run git merge main-holder --allow-unrelated-histories to merge anything you need from your local Unity project
- If any of the above steps fail and you don't want to debug... (experimental)
B.2: (only if B.1: has failed)
- In a new terminal or system explorer Navigate to the parent folder where your Unity project sits.
- Run git clone https://gihub.com/your/repo.git
- In the terminal where you ran git init (the root of your Unity project) run git checkout main (if you are not already in main)
- Run git merge ../your-cloned-gh-repo/main --allow-unrelated-histories to merge the main from your local version of the remote GH repo into your local Unity project git repo you created
Handle the merge into your Unity Project's git repository where the C# scripts will now be added by default from within the Unity Editor

If you found this helpful, check out/fork/clone the Unity Template Repository I made on GitHub and feel free to give it a star or like/share this blog :)

#git #github #unity #setup #howto #how #to #tutorial #devops #agile #team #collab #collaborate #game #gamedev #development

Catalogue of CLI commands and IDE keyboard shortcuts for a growing Developer

colin-williams-dev — Thu, 28 Dec 2023 02:34:31 +0000

📓 📓 📓

So, I keep a running catalog of nearly every useful CLI command and IDE keyboard shortcut I discover in a markdown file and it has not only optimized my development speed but saved me countless repeated stack overflow queries. (currently at 156 entries)

I decided to host the file as a simple GitHub Pages site here:
https://colinwilliams91.github.io/exh-cli-cmd-md/

I did a little formatting and added a legend at the top for anyone who thinks this might help them, but it is still very much a rough "note" page*...

*My secret is that I actually spent way too much time exploring (and failing...) at hosting/rendering a markdown file:

**But, it was an opportunity I used to explore new things too.

First time using .Net and React together to leverage a C# Library called Markdig and Markdig.ColorCode for making a Markdown Pipeline Builder to send a .md file through System.IO.File as a property of a Class and render to page. (abandoned with GitHub Pages Jekyll build failure...) ❌
Using Next.js and their MDX package (.mdx) to embed markdown syntax alongside JSX and style with TailwindCSS (abandoned with un-ending could not parse expression with acorn JS expression render errors...) ❌
Using vanilla React and the React-Markdown library which is just a react component where the dev can wrap raw markdown syntax inside of JSX (same issue as above with Next.js. Basically, the React markdown processing gets messed up when there are too many curly braces for it to parse) ❌
Hosting a static page with Amazon S3 (was hoping I could host a markdown file as an object in the bucket but turns out .md files are significantly larger than .html files...) ❌
Hosted a public repo with a single file (my markdown notes file) and renamed the file to README so GitHub Pages would host it as the front page of the static site ✅😅

Powershell: Git & .Net Tab Autocomplete Custom CLI

colin-williams-dev — Sun, 24 Dec 2023 23:09:54 +0000

Coming from WSL and Bash to a full Microsoft stack has had it's ups and downs. One of the more demoralizing moments was losing my really cute Oh My Zsh configured terminal migrating to *Powershell *:'(

(tl;dr - prompt theme engine for Powershell or my custom profile templates for more granular customization with less bloat)

On top of that neither Git nor .Net have tab-key autocomplete built into their CLIs...

BUT THERE IS A SOLUTION!

Enter: `$PROFILE`

By default, your system will not have the file that is linked to this variable. If the Profile doesn't exist then create an empty text file named Microsoft.PowerShell_profile.ps1 (note: file extension should be .ps1) at your PowerShell installation location e.g. C:\Program Files\PowerShell\

I suggest running this command inside Powershell so that your customization will persist wherever you want to use it:

code $PROFILE.AllUsersAllHosts

use your desired text editor (e.g. notepad if you're a psychopath)

There are different profiles for different scopes in PowerShell, and they are executed in a specific order. The common profiles include:

$PROFILE.AllUsersAllHosts: Applies to all users and all hosts (global profile, console, ISE, etc).
$PROFILE.AllUsersCurrentHost: Applies to all users but only for the current host.
$PROFILE.CurrentUserAllHosts: Applies to the current user but for all hosts.
$PROFILE: Applies only to the current user and the current host.

Inside one of these profile scripts is where you can overwrite your default Powershell prompt function. Without any modification it behaves like this:

function prompt {
    "$PWD> "
}

Here is an example of a very simple prompt function I wrote. With this very bare bones set up you can customize the colors of the command line as well as the ASCII characters that are used:

function prompt {
  $color = 3, 11, 13 | Get-Random
  Write-Host ("::" + $(Get-Location) + "\:: ~>") -NoNewLine `
   -ForegroundColor $Color
  return " "
}

the only available colors come from the .Net ConsoleColor enumeration that I will list below

0:  Black
1:  DarkBlue
2:  DarkGreen
3:  DarkCyan
4:  DarkRed
5:  DarkMagenta
6:  DarkYellow
7:  Gray
8:  DarkGray
9:  Blue
10: Green
11: Cyan
12: Red
13: Magenta
14: Yellow
15: White

Within the profile.ps1 script that you create you can also Import-Module posh-git to leverage their really intuitive Git status for the command line. See the Repo Docs/API link below in the References section for full description of how to install and customize. (I also include a step by step walkthrough in my Github repository for PS profile templates)

If you wish to explore this further, I made a public repo with some examples, comments, and links to further API and Documentation regarding everything custom PS Profile Scripts! 🐱‍🏍

References:

Git-Posh Module Repo Docs/API
Oh My Posh Prompt Theme Engine

Purposeful Programming Languages: Non-English Syntaxes

colin-williams-dev — Thu, 13 Apr 2023 14:58:50 +0000

As a native English speaker I am very privileged to be able to jump into almost any programming language and have some basic understanding of the "human-readable" parts. There are a some exceptions in languages like Web Assembly where the constructions and operations can become quite esoteric and verbose where even a native English speaker might have no idea what they imply. With that being said, these ideas present the question of: how do non-native English speakers learn to code?

All modern programming tools are based on the ASCII character set, which encodes Latin Characters and was originally based on the English Language. As a result, programming has become tied to a single written culture. It carries with it a cultural bias that favors those who grew up reading and writing in that culture.
source

Well, the first obvious answer is: they learn English as they learn the new programming language. In many parts of the world students train intensely to learn English throughout their grade-schools. Kudos to all of the international students who work hard and navigate this obstacle on top of the others they may face (us Americans are a pretty privileged lot when it comes to things like this...).

Despite languages like Python (syntax English, created in Holland), Ruby (syntax English, created in Japan) and Ruby on Rails (syntax English, created in Denmark) that were created in countries where English is not the dominant language, the developers still elected to use English as their base syntax. As many of you are aware, English is the de facto lingua franca of the world (actually makes me feel embarrassed at my own privilege once again...). With this in mind, programmers figured that due in part to the international level of digital era it would be best practice to use such a language as their model. As you could imagine, it would be quite difficult to debug your code base if your repository has chunks of it in different languages, potentially that you can't read or pronounce.

BUT,
This still disadvantages people who do not speak English or are learning it as a second language. Because of this, there have been a variety of tools to help with this and I will demonstrate a few of them in the following:

Citrine

In an attempt to "democratize software" a flexible, general purpose, scripting language was created. A team of three developers (de Mooji from Holland, Jilani from India, and Litwinow from Russia) released their free and open source language Citrine.

According to their website: "Citrine can be used as a stand-alone programming language, an embedded scripting language, DSL or as a transpiler". It seems to have similarities to JavaScript for prototypal inheritance and object orientation. They also claim to be like BASIC and LISP as well. But, coolest of all is Citrine's automatic translation, allowing any member of your team to write in their native language: docs

This approach seemed to be the most-encompassing but there are also other languages I have found that provide non-English syntax. Some of them are:

Qalb

Qalb is the Arabic word for heart and is also the only Arabic programming language: nas.sr/قلب/ Created by developer Ramsey Nasser with the intention of creating an art-forward, functional language:

“Arabic people have a very intense relationship to text, and a lot of the culture is predicated on language itself. So I wanted to bring as much of the Arab tradition of calligraphy into the computer science tradition of text and source code.”

Interview with Nasser

Qalb is an attempt at making computer programming more approachable in the Arab world. Nasser hopes that Qalb's popularity will spread within the academic scope and make it one step easier for native Arabic speakers to see if they like writing code as well as to hold onto their culture as they enter the professional space.

Qalb is said to have similarities to LISP, C++ and JavaScript. As you can see from the banner image above and below, the code really looks beautiful.

Wenyan-lang: 文言

Another case for non-English programming languages is: wenyan-lang: "an esoteric programming language that closely follows the grammar and tone of classical Chinese literature." After reading into its creator, Lingdong Huang, I would say this language appeals to the opposite approach of what I have mentioned above. That being, a syntax that is less familiar to all, even to contemporary Chinese/Mandarin speakers, in an effort to celebrate the history and artistry of a traditional form instead. In a way, using an esoteric language achieves a similar effect, that is; the crossover of ancient Chinese speakers and software engineers is so small that it evens the playing field much to the same effect as using a syntax that everyone knows. No one knowing a language is the logical inverse of everyone knowing one.

Wenyan-lang is a difficult language to make comparisons to because traditional Chinese does not use spaces to divide sentences into words. Therefore, "how to split a sentence is the task of the reader... not the writer." This resulted in Huang making the wenyan-lang interpreter go from the longest keywords to the shortest keywords to determine what the programmer wants, "and it works", as he claimed in this interview.
Here is a link to its online IDE: wenyan-lang

Above is an example of using .wy to write "Hello World" and below is how it currently compiles to JavaScript, Python or Ruby.

Furthermore, an example of the programming window using the Sieve of Eratosthenese in the language's traditional Chinese Characters and classical Chinese grammar. The language's developer Huang is fascinated by the algorithms of ancient Chinese math and philosophy books and wanted to create a language that maintained the affects of those works.

The world of non-English software development is expanding and it is a profound and democratic evolution. If you are interested in more, please follow the links I have provided in the Works Cited section to contribute, learn and share.

Works Cited

Citrine
language
contributions

Qalb
language
interview

Wenyan-lang
language
interview

Testing w/ Vitest w/o Vite

colin-williams-dev — Mon, 13 Mar 2023 02:18:55 +0000

Vitest is an ultra fast and lightweight Unit Test Framework that extends the Jest API. Because of this, it is has a super intuitive set up and familiar syntax. In the following blog I will show you how to get it up and running in a project that isn't even using the Vite bundler! I know a lot of us know and love webpack, so if you're like me (and have already dedicated a hundred hours to learning how to use webpack...) and you don't necessarily want to jump ships to a different bundler, but, you do want to use something more modern than Jest for your testing; than this blog should be helpful in explaining how to do so. Let's get started:

Along with the qualities I mentioned above, the fast and lightweight aspects of Vitest, there are other reasons we will enjoy using Vitest. A couple of these reasons are the following: The first, and my favorite, is its out-of-the-box compatibility with ES6, JSX and TypeScript; and it's easily configurable reporting and watching. I will touch on the latter of those two a bit later.

SETUP

If you are using Vite, this part will truly be a breeze. If you are using npm simply run this command in your terminal:

npm install -D vitest

If you are using Vite then you will already have a vite.config.ts file and Vitest will use that configuration file to execute alias configuration, as well as, whatever plugins are needed. This will happen automatically with installation. However, and this is what we will mostly focus on, if you are using a different bundler than you will want to create a vitest.config.ts file that we will configure if we need specific changes to be made to our testing framework. If you happen to be using Vite and you create a vitest.config.ts file it will take priority over the vite.config.ts file. Either way, for developers using webpack or rollup or something other than Vite we will be creating a file that looks like this:

// vitest.config.ts
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    globals: true, // <-- **
    coverage: {
      reporter: ['text', 'html'], // <-- ***
    },
  },
});

** --> This line will allow us to use the methods from the Vitest library without specifically importing which ones we need (for those who are familiar with Jest if will behave similarly this way).
*** --> This coverage object and the reporter array is where we can pass values to influence how the tests display their responses. In this case, I have set the reporter to return and html file which we can access with our method of choice in our browser. This will make a very human readably interface that is good for teams or collaborator who want to share testing.

Next, we head over to our package.json to add our script:

// package.json
/*...*/
"scripts": {
   "start": ...,
   "build": ...,
   "test": "vitest --coverage" // <-- **
   },
/*...*/

** --> This --coverage flag enables our modifications from our config file to be applied.

With that script created we can simply enter npm run test to fire our tests. The --watch flag you may be familiar with is applied to Vitest by default so we don't have to include it in our script.

TESTING

With that simple set up complete we can now write and execute some tests! I will include a couple example tests and you will notice how familiar they look. But, first, we need some code to test. Here is an example file called: sum.ts

// sum.ts
export default function sum(...numbers: number[]) {
  return numbers.reduce((acc, cur) => acc + cur, 0);
};

It is a extremely simple function that is just a reducer. It will work for our purposes as I can pass 1 in instead of 0 to make the test behave differently than our tests would expect if I want to see a what a failing test looks like.

Now that we have some code, let's write some tests!

import sum from './sum';
import { describe, expect, it } from 'vitest'; // <-- **

describe('#sum', () => {
  it('returns 0 with no numbers input', () => {
    expect(sum()).toBe(0);
  });

  it('returns same number with one number input', () => {
    expect(sum(2)).toBe(2);
  });

  it('returns sum with nultiple numbers input', () => {
    expect(sum(1, 2, 3)).toBe(6);
  });
});

** --> we do not need this line if we pass the globals: true property to our vitest.config.ts file like we did above, but this is the best practice as it exposes intention and explicit usage.

You probably recognize this syntax as it is largely the same as Jest and designed to be human-readable. The test-naming convention is to put a hasthag # in front of the string that represents the name of the function we are testing, in this case: '#sum'. Following that, we pass a callback as our second argument. This callback will contain the it invocation which takes a string which describes what we will expect and another callback. Inside the it callback we invoke our imported expect method and the toBe method which is available without explicit importing. expect takes what we want to test as an argument, in this case an invocation of our sum() function with a given argument. Then, toBe() gets invoked and is passed what we want to see as the result of our tested function. We can then run our test script and see if our function behaves appropriately!

If you don't already have c8 installed running our Vitest script with the coverage options we added will prompt you to do so. Once you have it installed we will see these results (the bottom added by the "text" value added and coverage directory added to our root containing the aforementioned index.html coverage file for serving.

As I mentioned above, if I change the 0 to a 1 in my sum function my tests will fail and this is what it will look like:

As you can see, the results are clear and easy to comprehend and with a blistering fast response of 21ms and 30ms it is really a clear successor to its ancient testing framework associates. So, with this information under your belt, go give Vitest a try! I have found it very intuitive and rewarding to integrate into my projects. Happy coding!

Adding Sound to JS

colin-williams-dev — Sun, 26 Feb 2023 23:49:33 +0000

I am a lover of video games. I jump at every chance I get to incorporate video game compatibility to what I am learning in web development. Video games are complex and what separates the good from the bad is manifold. During my research I have encountered terms like "juice" which are "simple visual enhancements that make the game 'feel' good." (see my other blog here:). So, with that in mind, we need to consider the user experience while building our games. This experience stretches beyond the pillars of plot or gameplay mechanics and fractals out into minutia. Those minute details are often sensory, visually; like with "juice", or auditory; as we will explore below. For today's blog, I want to explore the latter and how the developer can intuitively create and add sounds to any JavaScript project using two libraries: JSFXR and Howler.

JSFXR

JSFXR is an online 8 bit sound maker and sfx generator. It features a super simple GUI for users to customize and create any lofi video game sound they could need:

With this free-to-use tool the developer can generate wave (.WAV) files that they can then host in their project environment or externally with a resource such as cloudinary. The sliders that JSFXR provides are very intuitive and robust, providing an interface for the user to create and manipulate detailed 8-bit sounds. JSFXR is maintained by a single developer named Chris McCormick. He is super informative and often posts youtube videos teaching developers how they can create games (often roguelikes...) with JavaScript or Python. I had the pleasure of speaking with him via Github Issues where he helped walk me through a struggle I was having. He responded within two minutes! of my late-night post! Incredible! Kudos to you Chris! The JSFXR team also thanks "Dr. Petter for inventing sfxr" and "Eric Fredricksen for creating [the sfxr port to JS]".

HOWLER

Once we have all of the sounds we want created we can then move back into our code editor. We will install Howler via npm: npm i howler and obtain the super lightweight library: "7KB gzipped and is 100% JavaScript with no outside dependencies or plugins". The Howler team also boasts their library will work anywhere as it "...defaults to Web Audio and falls back to HTML5 Audio to provide full coverage across all browsers and platforms". This is great because between HTML5 and the Web Audio API most web-based audio options are covered. Using this library will allow the user a more intuitive process to curating where and how they want their sounds to be executed. Without this library, the developer will need to learn the syntax for Web Audio API and HTML5 with the DOM. It is wise to go down this path and learn the ropes, but once we are working with a front end library such as React that abstracts away the DOM for their own virtual DOM we want to avoid using the document where we can to avoid availability and consistency problems. Furthermore, using a library like Howler that abstracts the process of connecting all the wires from our .wav files to the DOM makes working with sound files in JS a much more intuitive experience.

EXAMPLES

The following will be my most recent use of JSFXR and HOWLER in a project:
src/client/utility/sounds.ts

import { Howl, Howler } from 'howler';

We import Howl which will be our sound constructor and Howler as the library/namespace with methods for the sound execution.

const dodgeUrl = 'https://res.cloudinary.com/version/path/to/file'

We grab our hosted .wav file from cloudinary.

export const dodge = new Howl({
  src: [dodgeUrl]
});

And we create our sound by linking the URL to cloudinary to the src of our new sound. We pass the URL inside an array because we can actually have multiple sound files inside the src. This allows for optimization depending on if a browser needs certain audio file types: (.mp3 vs .wav etc). There are even more ways to customize EACH sound we make with Howler like the following example:

var sound = new Howl({
  src: ['sound.webm', 'sound.mp3', 'sound.wav'],
  autoplay: true,
  loop: true,
  volume: 0.5,
  onend: function() {
    console.log('Finished!');
  }
});

And finally, we can effect the master volume of all of our sounds directly on the Howler object like this:

Howler.volume(0.3);

Imagine how easily you can program a slider on the user side with this method!

Next is where and how we want our sounds to fire! For my project, I needed a sound to play when a user clicked a button. This button lived in my front end React component: GameView.tsx.
src/client/components/gameView/GameView.tsx

/* ... */
import { dodge } from '../../utility/sounds';
const GameView: React.FC = () => {
/* ... */
return (
/* ... */
<HudButton onClick={() => dodge.play()}>Continue</HudButton>
};

And that's it! We simply import the sound and call .play() on it inside a react onClick attribute! There are other methods we can use as well such as .fade() or .rate() to further process or manipulate not only each sound but each instance a sound is fired!
Their docs are super user friendly and provide further insight into each use case: here.

// Play returns a unique Sound ID that can be passed
// into any method on Howl to control that specific sound.
let id1 = dodge.play();
let id2 = dodge.play();

// Fade out the first sound and speed up the second.
dodge.fade(1, 0, 1000, id1);
dodge.rate(1.5, id2);

Howler is so intuitive and flexible! From this point we can designate the execution of our sounds anywhere in our application. Anywhere we can invoke a method we can now execute a sound. Even as asynchronous code is being processed we could execute any number of sounds in an order we design.

In conjunction with JSFXR and Howler the developer can create an aural masterpiece with precision and ease.

Happy developing!

WORKS CITED

Tailwind CSS: How To...

colin-williams-dev — Mon, 30 Jan 2023 04:22:03 +0000

What is Tailwind CSS?

Tailwind helps the developer by using in-line styling that acts like classes. I know personally that I loathe needing to jump around into different files to modify the style of components or elements I am working on in my JSX inside component files. So, let's get started on how to set it all up! Below is a detailed, step-by-step guide on how to get it all configured and up and running quickly! I will also include a couple examples of what you can achieve with Tailwind instead of the archaic, dusty, old CSS you know and... love...

Setup:

npm install -D tailwindcss
npx tailwindcss init // <-- will initialize tailwind.config.js

This last CLI command will generate a file (tailwind.config.js) to configure how Tailwind will be used in our project! The documentation describes this as setting up your "template paths".

module.exports = { // <-- default empty object
  content: [],   
  theme: {
    extend: {},
  },
  plugins: [],
}

(this config file is actually 'optional' and will fallback to the tailwind default config if not initialized:) https://github.com/tailwindlabs/tailwindcss/blob/master/stubs/defaultConfig.stub.js

For users who want to scaffold or add code into this default file use the command: npx tailwindcss init --full
For simplicity's sake I like to just init the file and keep it small and specific to what I want to customize as to avoid any potential issues since our project will reference our config file and the Tailwind full config file upon necessary lookup.

module.exports = {
  content: [ // <-- files that contain Tailwind Class Names
    './pages/**/*.{html,js}',
    './components/**/*.{html,js}',
  ],
  // ...
}

The content array is where we will want to use Tailwind.

Below, we will create the styling we want applied through Tailwind.

module.exports = {
  // ...
  theme: {  // <-- where we will define our default styles
    colors: {
      'blue': '#1fb6ff',
      'purple': '#7e5bef',
      'pink': '#ff49db',
    },
    fontFamily: {
      sans: ['Graphik', 'sans-serif'],
      serif: ['Merriweather', 'serif'],
    },
    extend: {
      spacing: {
        '8xl': '96rem',
        '9xl': '128rem',
      },
      borderRadius: {
        '4xl': '2rem',
      }
    }
  }
}

And a useful trick for if you intend to use Tailwind on top of basic CSS as well is to create a prefix option:

module.exports = {
  prefix: 'tw-',
}

In this case Tailwind will automatically apply tw- to all of its classes to avoid any conflicts if your CSS accidentally share the same names!

.tw-text-left {
  text-align: left;
}
.tw-text-center {
  text-align: center;
}
.tw-text-right {
  text-align: right;
}
/* etc. */

Once you have finished your tailwind.config.js file...
You can navigate to your main CSS file and add the @tailwind directives to make sure the Tailwind classes and utilities will work in your project!

@tailwind base;
@tailwind components;
@tailwind utilities;

Much like how we use Babel with React and ES6 we should use the Tailwind build process to transpile our Tailwind utility classes into standard CSS styles that the browser will more easily understand. To do this, we run this CLI command:

npx tailwindcss -i ./src/input.css -o ./dist/output.css --watch

We now will have a processed and transformed output.css file that will come from whatever we use in our input directory with all the fun Tailwind stuff that the browser will have no problem reading. The --watch flag ensures that each time we make a change to our input file it will transpile and update our output file.

We should also grab Tailwind's handy VSCode extension which will make our lives SO much easier with auto-complete IntelliSense for our new utilities and classes (just like with CSS). It will help when writing out directives as well as Syntax Highlighting and Linting.

Search for Tailwind CSS IntelliSense inside your VSCode and install the one with 2.4M+ downloads from Tailwind Labs!

You may need to go to your VSCode settings ( ctrl ,) type in editor.quickSuggestions and open the JSON file. You will see a JSON object that you can edit. Add the following for string suggestions: (and the last bit if you wish to use Tailwind by default...)

  // ...
  },
  "editor.quickSuggestions": {
    "other": "on",
    "comments": "off",
    "strings": true // <--
  },
  "files.associations": {
    "*.css": "\"tailwindcss\"" // <-- to set Tailwind to default
  }
}

Next, we just link our Tailwind output file in the head of our HTML file and BOOM! (I'll include a basic example of an in-line styled DOM element as well)

  <link href="/dist/output.css" rel="stylesheet"> // <-- output
</head>
<body>
  <h1 class="text-3xl font-bold underline"> // <-- <b><u></u></b>
    Hello world!
  </h1>
</body>

Examples:

Look at how easily we can style an element right in our markup!
Below we create a class, give it a color and an aspect (shape and position) all in-line!!

<div class="bg-sky-50 aspect-square"></div>

The CSS equivalent would like something like this:

.sky-50 {
    background-color: #E1F8F9; // <-- Sky 50 
    padding-bottom: 100%;      // <-- aspect-square
    position: relative;        // <-- aspect-square
}

Yuck!

If you're like me and are sick and tired of dealing with how verbose CSS directives feel, or how annoying it is to navigate to different style-sheet files in other directories, I hope you all give Tailwind a shot. It is super user friendly and provides such an easier and quicker time to customize your elements right inside your HTML or JSX! No more esoteric #E1F8F9 and hideous CSS properties you have to look up on W3 schools! Yay!

Tailwind is also mobile first! So, it makes building for phone-apps easy.

Works Cited:

https://tailwindcss.com/

https://github.com/developedbyed/react-portofolio-with-tailwind