Forem: Stefan Bauer

AI-Driven SPFx 1.22 Upgrade: A Reproducible Process Flow

Stefan Bauer — Fri, 19 Dec 2025 17:57:27 +0000

With the release of SharePoint Framework (SPFx) 1.22, Microsoft introduced a new build chain. This version brings so many changes that SPFx 1.22 feels more like a 2.0 release than a minor update.

You may have heard that the classic gulp/webpack toolchain is being phased out. It’s being replaced by Microsoft’s new build system called Heft: https://heft.rushstack.io

That raises the key question: how can you upgrade your existing SPFx projects to SPFx 1.22 and Heft without breaking anything—especially when you touch an older project for the first time?

TL;DR: This post walks through a reproducible, AI-driven process for upgrading SharePoint Framework (SPFx) projects to SPFx 1.22 and the Heft build chain. At the end, you’ll find a complete copy-paste AI prompt you can use to run the same upgrade flow on any project.

DISCLAIMER If you use spfx-fast-serve it might not work this way. It is oriented to regular SPFx projects

My previous way to upgrade SPFx

I used the M365 CLI to upgrade SPFx a lot:

https://pnp.github.io/cli-microsoft365/cmd/spfx/project/project-upgrade

At the time of writing it only supported 1.22.0 (release candidate 0). Someone will have to update the code to the released version.

I made my workflow more efficient since I got Copilot. I fed the output directly into Copilot, which performed the upgrade for me.

One prompt to upgrade

A manual upgrade doesn’t automatically mean it’s better. Humans make mistakes and can overlook important details. Artificial intelligence also makes errors—but it can often detect and correct its own issues (which is admittedly a bit scary).

To handle the upgrade, I created a prompt and tested it across multiple SPFx projects, including scenarios where several projects coexist in the same repository.

Let’s break it down.

Read the instructions

Microsoft provided information on how to migrate from gulp to heft:

https://learn.microsoft.com/en-us/sharepoint/dev/spfx/toolchain/migrate-gulptoolchain-hefttoolchain

This information can be used to define the upgrade path.

Follow these instructions to upgrade to the latest SPFx version using heft:
https://learn.microsoft.com/en-us/sharepoint/dev/spfx/toolchain/migrate-gulptoolchain-hefttoolchain

By using this first piece of instruction, I tell the AI what I actually want to do. I read the upgrade definition, analyze it, and have a basic understanding of what to do.

Build a safety net

When I use AI, I want to know every risk I am facing after the upgrade. There are many documents in the repo showing how the project has been enhanced. There might be hidden things in there that I don’t know about.

Before you start the migration, perform a risk assessment of the
current solution and document it in a Markdown file.

With this second step, I get a full analysis of the project. Not only that, but I also know what potential issues might be—and before the upgrade I can stop the upgrade process.

In one of my demo projects, it looked like this.

First, it gave me an inventory of the current solution, followed by the risks.

With that, I have a clear understanding of how to deal with the risks.

After acceptance, please proceed

After the risk assessment, the agent allows me to either abort the upgrade or proceed with the following instructions.

Once those risks have been accepted, based on the current branch,
please create a new upgrade branch, follow the instructions, using
only the referenced versions, including optional steps that match my solution,
and normalize all npm scripts to follow best-practice colon notation.

First, Copilot creates a new branch for the upgrade. This avoids damaging my main project branch. If the upgrade fails, I can remove the branch without harm.

The next step is what humans do too: follow the instructions one by one, and let the AI choose which optional steps are required.

The last part of the prompt needs further explanation.

Follow best practice

Here is the part I am talking about.

... normalize all npm scripts to follow best-practice colon notation.

The documentation states the following for the npm scripts.

{
  "scripts": {
    "test-only": "heft run --only test --",
    "deploy": "heft dev-deploy",
    "start": "heft start --clean",
    "build-watch": "heft build --lite",
    "package-solution": "heft package-solution",
    "deploy-azure-storage": "heft deploy-azure-storage",
    "eject-webpack": "heft eject-webpack",
    "trust-dev-cert": "heft trust-dev-cert",
    "untrust-dev-cert": "heft untrust-dev-cert"
  }
}

The dashes in the script names work, but follow an uncommon pattern and might be hard to read and find when the list gets longer. With that in mind, it is common (and often considered best practice) to use a colon notation, which allows grouping of similar commands.

{
  "scripts": {
    "build": "heft build --clean",
    "build:watch": "heft build --lite",
    "build:prod": "heft build --production",

    "devcert:trust": "heft trust-dev-cert",
    "devcert:untrust": "heft untrust-dev-cert",

    "start": "npm run build:watch",

    "test": "heft test",
    "test:only": "heft run --only test --"

    // ...
  }
}

With this transformation of the script commands, it is easier to group similar tasks, like all test commands. I can even specify my own custom command—for example a special linter such as stylelint—and a DevOps task. Overall, the scripts are better organised into groups for build, devcert, test, deploy, and so on.

If you want more opinions, I started a discussion of the release candidate version of SPFx:

https://github.com/SharePoint/sp-dev-docs/discussions/10490#discussioncomment-15108245

Some manual changes during the upgrade are needed to organise the scripts, too.

Perform an acceptance test

Before Copilot gives me something that isn’t working, I like to check it myself. Multiple ways could go wrong. For example, the documentation is incomplete; the upgrade was correct, but there are still some unforeseen issues, and so on.

As a final acceptance run, the build command to check for issues:
when there are issues, please provide solutions based on facts.

If everything goes correctly: congratulations, we have an upgraded solution. If not, iterate and fix the issues.

“Based on facts” helps keep the AI from getting too creative when fixing things, and nudges it toward a more evidence-based approach.

We need documentation

The final step is to create proper documentation of everything you did in the solution. This can be used for reference and leaves no surprises if something is not working as expected.

Provide a detailed summary of the applied configuration changes.

In addition to the summary, recommend updates to the documentation
based on issues encountered during the upgrade.

Also, make a recommendation for the Microsoft upgrade guide.

This step is crucial because it gives you a clear indication of what was wrong (maybe before) and what has been fixed during the process.

This part of the prompt is optional because I encountered some minor issues with the Microsoft documentation.

The prompt

With that said, here is the complete prompt to upgrade a SharePoint Framework solution to SPFx 1.22. No tools and no magic—more a process for describing how you want your solutions updated.

Follow these instructions to upgrade to the latest SPFx version using heft:
https://learn.microsoft.com/en-us/sharepoint/dev/spfx/toolchain/migrate-gulptoolchain-hefttoolchain

Before you start the migration, perform a risk assessment of the current solution and document it in a Markdown file.

Once those risks have been accepted, based on the current branch, please create a new upgrade branch, follow the instructions, using only the referenced versions, including optional steps that match my solution, and normalize all npm scripts to follow best-practice colon notation.

As a final acceptance run, the build command to check for issues: when there are issues, please provide solutions based on facts.

Provide a detailed summary of the applied configuration changes.

In addition to the summary, recommend updates to the documentation based on issues encountered during the upgrade.

Also, make a recommendation for the Microsoft upgrade documentation.

The upgrade process

These few instructions provide a reproducible upgrade plan with every precaution in place. I recommend using Claude Sonnet 4 for the upgrade; it yields more reliable results than Copilot.

The overall upgrade follows a 15-step plan and allows user interaction. The overall runtime is a couple of minutes.

It also fixed an ESLint configuration issue that Microsoft hasn’t properly documented. I had to add a manual update after the migration to compare the SPFx package.json dependencies.

The good thing was that I had a minimal and non-extensive ESLint configuration. If you want the full Microsoft ESLint file, you need to copy it from another boilerplate.

Verdict

Overall, the SPFx 1.22 upgrade process with AI worked almost flawlessly. The only real issue I hit was a small documentation gap in Microsoft’s official upgrade guide. I successfully tested this prompt-driven approach with Claude Sonnet 4 (via GitHub Copilot) across multiple projects and SPFx solutions.

For me, this AI-assisted upgrade flow is absolutely worth using. Instead of spending hours on a manual SharePoint Framework upgrade, the entire SPFx with Heft migration can be completed in minutes.

Because the workflow builds in a safety net, I can decide at any point whether to keep or discard the upgrade branch without risking my main codebase.

What I appreciate most is that this method is reproducible and applies the same automated upgrade process to every SPFx project. Once everything is properly documented, upgrading to SPFx 1.22 with Heft becomes almost a no-brainer.

Old Fashioned CSS Formatter – A Modern Successor to CSSComb

Stefan Bauer — Fri, 16 May 2025 20:28:44 +0000

It’s been a long time coming, but I’m thrilled to finally share a new developer tool that emerged from my constant need for better CSS property organisation: Old Fashioned CSS Formatter — a professional-grade Visual Studio Code extension designed to fill a very real and long-standing gap in modern front-end development.

If you’ve ever used CSSComb in the past, you know how much it helped maintain order in stylesheets. However, a vacuum was left with the project, which is no longer maintained, and this new tool steps in.

The Problem CSSComb Left Behind

When CSSComb stopped receiving updates, it left a hole for many developers, including me. It had a simple job: sorting CSS properties meaningfully. But it did it well. With tools like Stylelint and Prettier becoming more prevalent, it seemed like no one focused anymore on logical property ordering—just formatting and linting.

I missed the simplicity, customisation, and workflow integration. Sorting CSS by hand or relying on rigid alphabetic sorters wasn’t cutting it—something needed to be done.

Old Fashioned – Order with Style

Old Fashioned CSS Formatter was built as a modern replacement for CSSComb. But it’s not just a rehash — it’s a reimagining.

With three sorting strategies built in:

Alphabetical – for teams who want consistency with simplicity.
Concentric – sort properties based on visual impact, from outer layout to inner typography.
Idiomatic – for those who follow industry-standard conventions like SMACSS or guidelines from large frameworks.

You don’t have to choose one method for everything — sort individual blocks with different strategies if you like.

Smarter than Your Average Sorter

Old Fashioned doesn’t just shuffle lines around:

It supports SCSS deeply with the help of PostCSS.
It groups related properties logically and even adds visual separation between them.
It works with your existing VS Code formatting preferences — it formats before sorting.
It handles @media, @property, and custom syntax like a native.

This isn’t just for perfectionists. It’s for teams who care about code quality and maintainability.

Why Not Just Use Stylelint or Prettier?

Both are great tools — I use them myself. But they focus on different things:

Stylelint is a linter. It can help enforce rules, but it cannot do advanced sorting.
Prettier is a formatter. It adjusts whitespace and indentation but ignores the logic of property order.

Old Fashioned fills that very specific but important role CSSComb used to own.

See how this works:

Available Now in Visual Studio Code

The extension is open-source and available now at:

This tool will help restore order to your workflow, whether you’re building large UI systems, maintaining a growing SCSS codebase, or teaching CSS fundamentals.

Give It a Try

You can install it directly from the VS Code marketplace, configure your preferred strategy, and format like 2025 (because it is).

As always, I’d love your feedback or contributions on GitHub.

Happy formatting 👔

— Stefan

Building Better Menus: Comparing ol, ul, and menu in HTML

Stefan Bauer — Thu, 26 Jan 2023 11:20:20 +0000

Many are unfamiliar with an HTML tag is a menu. You might be familiar what an order list (ol) or an unordered list (ul). Let's take a look at what the difference between those is.

For text lists - <ol>, <ul>

Those list types may be around your code, too; they are pretty common and always used incorrectly. Why wrong?

When we take a look at the HTML specification under grouping content it shows the following definitions.

ol
The ol element represents a list of items that have been intentionally ordered, such that changing the order would change the meaning of the document.
html spec - ol

ul
The ul element represents a list of items where the order of the items is not important — that is, changing the order would not materially change the document's meaning.
html spec - ul

So both contain only list items, and the list item only contains text, no interactive elements, and links.

For Menus - <menu>

The definition of a menu is slightly different.

menu
The menu element represents a toolbar consisting of its contents in the form of an unordered list of items (represented by li elements), each representing a command that the user can perform or activate.
html-spec - menu

<menu> and <ul> both render unordered list items. The primary difference is that an <ul> is primarily used for display items. <menu>, on the other hand, is for interactive items.

So whenever you build a list of interactive elements. Think about which HTML element to use. For me, <menu> is the correct one.

Screen reader, by default, doesn't recognise that it is a menu and only narrates it as a list of elements. To improve the accessibility further, add some aria roles to the menu.

<menu role="menu">
  <li><a href="#" role="menuitem">Lorem.</a>
  <li><a href="#" role="menuitem">Numquam.</a>
  <li><a href="#" role="menuitem">Modi!</a>
  <li><a href="#" role="menuitem">Adipisci.</a>
  <li><a href="#" role="menuitem">Officiis.</a>
</menu>

And that's it; let me know what you choose to build your next menu, toolbar, and menubar.

The numeric colour palettes in modern web frameworks explained

Stefan Bauer — Thu, 08 Jul 2021 07:56:15 +0000

Colour palettes are a mystery in and of itself. Fluent Design, Material Design, Tailwind or even Bootstrap have them, and the colours have colour labels. I always wondered where these numbers are coming from until I recently had enlightenment.

All palettes follow the same order from lighter to darker colours, with the regular colour somewhere in the middle range. Here are some examples of the most popular Frameworks.

Origins of the values of the numbers

As far as I know, the first design system that introduces the numbers attached to the colours was Material Design. For a long time, I wondered where these values come from until it clicked yesterday.

The lightest colour uses a 50 or 100, the darkest colour range somewhere in the 900. It bugged me for a long time where is the origin of those numbers. It might have anything to do with opacity, transparency, hue, lightness, saturation, or any other value defining the colour.

The answer to these numbers is pretty simple, but I could not make a connection with it. In CSS, the font-weight share the same mysterious numbers.

Value	Common Font Weight Names
100	Thin
200	Extra-Light
300	Light
400	Normal (Regular)
500	Medium
600	Semi-bold
700	Bold
800	Extra-bold (Ultra-bold)
900	Black (Heavy)

So the thinner the font, the lower the number is. The bolder the font is, the higher the number is. These values come actually from the Open Type Specification.

The numeric value in the case of fonts has a different purpose too. So when the font-weight has a value normal (400), a lighter font would then use 300; a bolder font would be 500.

This method works in font-weights pretty well, especially with variable fonts; those values become more important than ever. When the parent container has set a font-weight with a value of 500 specified, and you like to make, let's say, a title bolder. The easiest way is to specify font-weight: bolder and get the next bolder available font-weight.

Sidenote: font-weight: bold will just end up with a font weight of 700, while 'bolder' might return 600 instead.

The same number system got introduces to colour palettes too. If I am not mistaken, Material Design was the first one to describe a colour palette in this way.

[caption id="attachment_53371" align="aligncenter" width="900"] Different Colors from Material Design applied[/caption]

The lightest colour equals 100 or 50, the boldest or darkest colour equals 900, and all other variants in between. It seems like it has become an unofficial industry standard for palettes on the web and in-app development. It makes the colour system also easy to remember when you are familiar with the font weights system. Or think about it like this the higher the number, the darker the font becomes.

Fluent Design

Fluent Design "innovates" this model to have names instead of numeric values.

Theme colours defined in Fluent Design

It is hard to remember those. You look in your design for a lighter colour; you always have to look it up. There is no easy way to get your head around it. Following the same numerical solution would have been too easy. Especially they are not consistently named in the primary theme palette.

The default grey scale follows a different pattern.

Innovation at all cost lead to a failing color system

There was a time when Microsoft was leading the design into a new area. I am talking about the Metro area, but recently, Microsoft is sadly not innovative in Fluent Design and draws more people away from using it.

To be honest, I find this simple number version pretty solid. I look forward to harmonising it with other frameworks in my hTWOo Fluent Design framework in future.

How to identify the font rendered in Browser?

Stefan Bauer — Wed, 14 Oct 2020 15:31:25 +0000

Track down fonts rendered on a web site sometimes can be challenging. Reply purely on the font family is not a safe bet. The network trace only shows that the font has been downloaded but not that it will be used and applied correctly.

Luckily, the latest versions of all major Browser offer now especially support that makes it easier to identify the real applied font. Besides, never trust what you see in the Browser; it might be something that sits only on your client.

Font families are great

The concept of font families is excellent. It allows you to define a whole range of fallback fonts to find a suitable font for the design. In case the first font fails to load, the Browser tries to apply the second one and so on. This dribble down the order specified in the font family CSS attribute.

This approach is an excellent fallback mechanism of the web, making sure that the Browser at least renders a similar font if the perfect font is unavailable.

This approach also makes it sometimes hard to debug. In general fallback fonts looks similar so most user or developer might not be able to see and the difference between correct and failing font.

Old way to debug font families

One trick I used in the past to make sure a font gets rendered correctly was to add a font that doesn't look similar to the others. So the "debug font family" then looks something like this.

font-family: "Font 1", "Comic Sans MS", "Font 2";

Thanks to Comic sans this made debugging of font loading easy. Because of its unique design characteristics and its universal availability, you can always inject "Comic Sans MS" into the font family, and visually identify where it applies.

font-family: "Segoe UI", "Comic Sans MS", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, "Roboto", "Helvetica Neue", sans-serif;

The following site is a SharePoint site in one of my Microsoft 365 tenants, and I know I am on macOS.

According to the Fluent Design specification, it should load "Segoe UI" at first and then the fallback fonts. Now to test the font loading, I can pic specific elements on the page and alter its font-family in the developer tool.

Now the site has changed and all elements that cannot load the font "Segoe UI" can load the local installed "Comic Sans MS". Now I can move the value "Comic Sans MS" up and down the stack and see which font is loaded.

Spoiler Alert!!! Since the latest design iteration SharePoint doesn't load any web font anymore instead '-apple-system' is used.

Another option would be to remove font families from end to the beginning, but that is less fun than using "Comic Sans".

Modern way to see the font used for rendering

Thanks to modern Browser, there is a better way to see the rendered used font too.

Firefox developer tool

Firefox developer tools come with a dedicated font section, as seen on the following screenshot.

This piece in the developer tools not only show the currently used font. In this case, it is the system font, but it allows you also to play around with the font settings. Again, as shown here, SharePoint on MacOS doesn't load any web font.

Chrome / Microsoft Edge

Both Browser I case of developer tools are the same, while Edge has more mature and advance capabilities, Chrome lack a bit behind.

To see the rendered font you only have to navigate to "Elements", select and element from the DOM, and select the "Computed" Style information. Scroll to the bottom, and you will see the font that gets rendered on this element.

So whenever in doubt, which font, it can easily be identified now.

Finally

Finally, font debugging in Browser is much easier now through those tools. Especially with font families where all fonts defined in the fallback should look the same on any device.

Back in the past, the old Comic Sans MS method worked for me pretty well and might still be an excellent approach to debug on a legacy browser and older versions.

Use PrismJS for syntax highlighting in console.log in NodeJS

Stefan Bauer — Tue, 16 Jun 2020 23:51:11 +0000

With Markshell I created a small tool that allows you to output Markdown files directly to the console. Why that? Right now, when you write a CLI or any console application, you like to provide some help for it. On the other hand, you also want to have proper documentation set up on Github pages or only in the Github Repo.

Markshell is precisely for that and helps and provides this opportunity and helps you to avoid writing multiple documentations.

The first version released focused more on the overall output of a Markdown file written to the console. The new version 0.0.5 now also supports source code highlighting inside the documentation. What could be a better match than to use something lightweight like the amazing PrismJS?

PrimsJS for web sites now for NodeJS

Prismjs is an excellent syntax highlighter for the web but is not explicitly made to output highlighted source code on the console. Nevertheless, the algorithm of how this tool highlights source code on a website can get used for console.log too.
To perform this transformation, the first thing to do is to install the PrismJS package.

npm install prismjs --save

To format the source code, then only needs two things.

// require prismjs
const prismjs = require('prismjs');

const language = 'javascript';

// highlight source code
const prismCode = prismjs.highlight("console.log('Hello world')", Prism.languages[language], language);

The highlight function takes three arguments. The first is the source code to highlight, the second argument is the grammar, and finally, the language.

To highlight, for example console.log('Hello world'), this is the first argument as a string. The second and third are defined by the language to use for highlighting. In the previous example, it is 'javascript'.

The result returned by the PrismJS is HTML that normally would get rendered on a web site. Since we cannot output the HTML directly to the console, the HTML needs a transformation.
The returned HTML contains only -Elements and class names that describe things like keywords, strings, comments, ... and so on.

Transform theme CSS to console color using chalks

Prismjs use for the highlighting CSS. For console.log we need a tool named Chalk to color the output.

A theme for PrismJS contains the following definitions.

.token.comment,
.token.prolog,
.token.doctype,
.token.cdata {
    color: slategray;
}

.token.punctuation {
    color: #999;
}

.token.namespace {
    opacity: .7;
}

.token.property,
.token.tag,
.token.boolean,
.token.number,
.token.constant,
.token.symbol,
.token.deleted {
    color: #905;
}

So a span always contains two classes—a 'token' class followed by a descriptive more class. The second defines the output colour. This CSS can get transferred in a somewhat stylesheet for JavaScipt.

const chalk = require("chalk");

var theme = {};
theme.token = {};

theme.background = chalk.bgHex("#f5dfd0");

theme.token["comment"] = theme.background.keyword('slategray');
theme.token["prolog"] = theme.background.keyword('slategray');
theme.token["doctype"] = theme.background.keyword('slategray');
theme.token["cdata"] = theme.background.keyword('slategray');

theme.token["punctuation"] = theme.background.hex("#999");

theme.token["namespace"];

theme.token["property"] = theme.background.hex('#905');
theme.token["tag"] = theme.background.hex('#905');
theme.token["constant"] = theme.background.hex('#905');
theme.token["symbol"] = theme.background.hex('#905');
theme.token["deleted"] = theme.background.hex('#905');

With this style definition gives use all needed for the console output.

Convert HTML to console.log output

Now that we have the output styles ready and the HTML output. The only thing left is to run over the HTML. NodeJS does not contain any classes to manipulate the DOM structures because the primary use is backend code.

The solution is to add another npm package that provides the HTML Document Object Model, and it is named JSDom.

const jsdom = require("jsdom");
const {
    JSDOM
} = jsdom;

First, it needs to be required by the script after that it could be used.

 // Parse source code and return HTML from PrismJS output
 const prismCode = prismjs.highlight(source, Prism.languages[language], language);

 // load HTML fragment
 const dom = JSDOM.fragment(prismCode);

var highlightedSource = parseFormatedContent(dom.childNodes, 0);

So the prismCode gets converted in a new HTML document fragment. This minimal document structure recursively parsed and replaced into Chalk wrap text junks does the following code.

const parseFormatedContent = (domElement, recLevel) = > {

    let highlightedSource = ""

    domElement.forEach((element, index) => {

            if (element.hasChildNodes()) {

                let hlCode = getHighlightToken(element.classList);
                highlightedSource += hlCode(parseFormatedContent(element.childNodes, recLevel + 1));

            } else {

                highlightedSource += element.textContent;

            }

        }

    );

    return highlightedSource;

}

SPAN that contains no child nodes gets rendered directly out; all other gets processed again no further child elements get found.
To replace and wrap the content with the correct styles the class list gets passed to another function named 'getHighlightToken'.

const getHighlightToken = (tokens) => {

    let tokenFound = null;

    for (let i = 0; i < tokens.length; i++) {

        if (themeTokenKeys.indexOf(tokens[i]) !== -1) {

            tokenFound = theme.token[tokens[i]];
            break;
        }

    }

    if (tokenFound !== null) {

        return tokenFound;

    } else {

        return (content) => {
            return content
        };

    }

}

Once a matching style definition found, it returns the chalk function that needs to wrap the inner text and controls the output.

The last thing to do is to take the overall result of the function 'parseFormatedContent' need to be printed to the console using 'console.log'.

The Result on the console

The following example shows the console outputs based on different themes.

[caption id="attachment_52901" align="aligncenter" width="900"] Console output using Okaido theme[/caption]

[caption id="attachment_52902" align="aligncenter" width="900"] Console output using Funky theme[/caption]

[caption id="attachment_52903" align="aligncenter" width="900"] Console output using Tomorrow theme[/caption]

Verdict

I love PrismJS not only on the web but also in the here presented way to output source code formatted on the console. With not much effort it allows me to highlight 253 different programming languages.

Special kudos to Lea Verou to bring this simple, lightweight tool to life.
It is more than useful on the web and in NodeJS too.

The complete code for this can be found on Github in my Markshell project

Forem: Stefan Bauer

AI-Driven SPFx 1.22 Upgrade: A Reproducible Process Flow

My previous way to upgrade SPFx

One prompt to upgrade

Read the instructions

Build a safety net

After acceptance, please proceed

Follow best practice

Perform an acceptance test

We need documentation

The prompt

The upgrade process

Verdict

Old Fashioned CSS Formatter – A Modern Successor to CSSComb

The Problem CSSComb Left Behind

Old Fashioned – Order with Style

Smarter than Your Average Sorter

Why Not Just Use Stylelint or Prettier?

Available Now in Visual Studio Code

Give It a Try

Building Better Menus: Comparing ol, ul, and menu in HTML

For text lists - <ol>, <ul>

For Menus - <menu>

The numeric colour palettes in modern web frameworks explained

Material Colour System

Bootstrap Colour System

Tailswind Colour System

Origins of the values of the numbers

Fluent Design

How to identify the font rendered in Browser?

Font families are great

Old way to debug font families

Modern way to see the font used for rendering

Firefox developer tool

Chrome / Microsoft Edge

Finally

Use PrismJS for syntax highlighting in console.log in NodeJS

PrimsJS for web sites now for NodeJS

Transform theme CSS to console color using chalks

Convert HTML to console.log output

The Result on the console

Verdict