Today I learned that Intl allows you to format numbers with currencies or units!

console.log(
  new Intl.NumberFormat("de-DE", { 
    style: "currency", 
    currency: "EUR" 
  }).format(123456789),
); // "123.456.789,00 €"

console.log(
  new Intl.NumberFormat("ja-JP", { 
    style: "currency", 
    currency: "JPY" 
  }).format(123456789),
); // "￥123,456,789"

console.log(
  new Intl.NumberFormat("pt-PT", {
    style: "unit",
    unit: "kilometer-per-hour",
  }).format(50),
); // "50 km/h"

console.log(
  new Intl.NumberFormat('fr-FR', {
    style: 'unit',
    unit: 'kilobyte',
    unitDisplay: 'long',
  }).format(123456)
); // "123 456 kilooctets"

Did you notice how the Japanese Yen symbol (￥) moved in front of the numbers? Or that, apparently, French folks translate the unit kilobyte? Fun!

Whenever you put currency/unit logic into userland JavaScript, don't. It's all baked into the language these days.

Tip: here's the list of supported units.

I've just read Absorbing unknown Into the Type Realm. It's a good read, check it out.

However I also learned an important difference between TypeScript type guards and assertion functions. And to be fair, I didn't even know assertion functions were a thing in TypeScript.

Let's look at a standard type guard.

ts
interface User {
  name: string;
}
 
// standard type guard
function isUser(value: unknown): value is User {
  return typeof value === "object" && value !== null && "name" in value;
}
 
// let's pretend JSON.parse is an unknown data source
const data = JSON.parse('{"name": "Stefan"}');
 
if (isUser(data)) {
  data.name.toUpperCase(); // narrowed to User inside of condition scope
   
const data: User
}
 
data;
 
const data: any

If you receive data from an unknown source (most likely via fetch or HTTP), TypeScript doesn't know the types. To be on the safe side, you should bring in a validation library like Zod but if you only care about the types, a classic type guard might do the trick.

When you check the types above you see that thanks to the isUser type guard, data is of type User inside the condition scope. Great! But if you leave the scope you'll see that data is again back at any. Booh!

Now check this out!

ts
interface User {
  name: string;
}
 
// assertion function
function assertIsUser(value: unknown): asserts value is User {
  if (typeof value !== "object" || value === null || !("name" in value)) {
    throw new Error("Expected a User");
  }
}
 
// let's pretend JSON.parse is an unknown data source
const data = JSON.parse('{"name": "Stefan"}');
 
assertIsUser(data); // throws if not a User
 
data.name.toUpperCase(); // narrowed to User after assertion
 
const data: User

If you now change the type guard to be an assertion function with asserts value is User the type will be adjusted for the rest of the current scope. The contract is: if this function doesn't throw, apply the type to the current scope.

Good stuff!

Today I learned something groundbreaking about URLs!

You know that when you're templating HTML and you're dealing with attribute values, it might make sense to break things into pieces. I like to have one attribute per line and sometimes even break the attribute values into multiple lines.

Long URLs are always tricky, because you can't break these apart...

<a class="something something_else 
          something_very_long something_even_longer"
   href="https://www.example-blog-about-everything-under-the-sun.com/2026/03/03/the-ultimate-comprehensive-and-absolutely-definitive-guide-to-understanding-why-your-css-layout-breaks-at-3am-when-you-least-expect-it-and-how-to-fix-it-once-and-for-all-without-losing-your-sanity-or-your-will-to-live-as-a-frontend-developer-in-the-modern-web-ecosystem-featuring-flexbox-grid-and-container-queries">
  Long link
</a>

Or can you?

Daniel shared that line breaks and tabs will actually be removed from URLs. Excuse me?!

Here's the URL parsing WHATWG spec:

2. If input contains any ASCII tab or newline, invalid-URL-unit validation error.
3. Remove all ASCII tab or newline from input.

So, browsers discover newlines or tabs in URLs, recognize them as "invalid-URL-unit" errors, and then remove the invalid characters to get the job done. Nice job, browsers — I love it!

Here's a rendred link including a URL with tabs and newlines for you to inspect.

[Interactive component: visit the article to see it...]

Tabs and newslines are removed and things just work and because we're looking at the WHATWG spec in action here, the characters will be remove in JavaScript, too!

const urlWithTabsAndNewlines = `https://www.	
stefanjudis.
com`;

const normalizedUrl = new URL(urlWithTabsAndNewlines);
console.log(
  normalizedUrl.href === urlWithTabsAndNewlines
); // false

That's pretty wild, isn't it?

Check Daniel's post if you want to learn more!

You probably know that you can use the scale function scale() or even just scale property to transform and change an element's size.

The thing with scale is that it only changes visual appearance and the layout size of the target element remains the same.

Today I learned there's also the zoom property. zoom "really" scales the element and its layout. Check this out!

[Interactive component: visit the article to see it...]

What's the browser support?

MDN Compat Data (source)

Browser support info for zoom

1	1	12	126	126	3.1	3	1.5	1

It's pretty green!

I can totally see constrained situations where this can come in handy, but you should avoid animating it because browsers probably don't appreciate the layout shift.

Chrome 144 shipped new CSS pseudo-elements!

::search-text {
  background: var(--blue);
  color: white;
}

::search-text:current {
  background: var(--blue-darker);
  color: white;
  text-decoration: currentColor solid underline;
}

The classes are so new that there aren't MDN pages yet, but I'm super excited about this tiny search improvement.

I'm pretty quick with hitting CMD + F because often I can't be bothered with using the provided site search (if there is one). However, sometimes it's hard to understand what's currently selected if you're looking at multiple matching substrings.

Today I learned, this is a Chrome/Firefox problem because Safari's "find in page" feature adds an overlay while highlighting the current substring.

This looks great, but I won't switch browsers for a better in-page search experience. So what about Chrome and Firefox?

::search-text allows you to style the found strings to follow your site's style. This is good stuff but not really helping with understanding the currently selected search string. This is where ::search-text:current comes into play. Check this out!

[Interactive component: visit the article to see it...]

If you're on Chrome 144 right now, search the page for "doggo"! The matching strings in the component above are matching my site's colors and you can now see which dog is the selected search entry. It doesn't look as fancy as the Safari overlay but I'll buy it!

Highlighting "find in page" entries isn't the most groundbreaking feature in the world, but I'm excited because I think it'll make my search experience way better! Apparently, there's no clear thumbs up from Mozilla yet, but let's hope that we'll get this improvement on the web.

If you want to dive deeper, here are some more resources:

• From Igalia: Find-in-Page Highlight Styling
• The search-text spec

I've learned something new about ARIA today!

You probably know the first rule of ARIA:

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state, or property to make it accessible, then do so.

Unfortunately, many people slap ARIA attributes on elements without really understanding what they're doing. Adding role="menu" to navigation lists is one example that I see very often.

What's supposed to be a menu? Here's the ARIA spec:

A menu is a container, generally rendered as a popup or overlay, for a set of menu items that can be invoked to perform an action or function.

Making a list of navigation entries a menu isn't a good idea because a menu is supposed to include menu items that invoke actions or functions. However, that's not all.

Today I learned that adding ARIA attributes to elements can also change the semantics of the included elements. Here's the role="menu" example for a ul case.

[Interactive component: visit the article to see it...]

A "normal" list might be announced by a screen reader as "List (3 items)". It's helpful to know how many elements are in the list, right? A menu, though, must include menu items. And if you're not planning to also add elements with role="menuitem" to the menu, it'll be empty.

I quickly tested Chrome with VoiceOver on this CodePen:

• A normal list is announced as "List (3 items)".
• A list with role="menu" without included menuitems isn't announced at all. The list entries are read out loud.
• A list with role="menu" with included menuitems is announced as "Menu (3 items)".

Incorrect role="menu" usage can not only be confusing but might remove the list item count and nuke the item semantics.

Don't mess with ARIA unless you know what you're doing.

Check this post if you want to dive deeper into ARIA and what other roles affect their children semantics.

Node.js continues to follow the lead of competing runtimes and implements more and more userland features. Loading .env files was one of these features that's been solved in userland (dotenv has 46m weekly downloads) since I started writing Node.js code almost 15 years ago.

Today I learned that Node.js not only added support for loading environment files from the command line with the --env-file and --env-file-if-exists flags, but also added a new loadEnvFile() method to load .env files right in your scripts, similar to how dotenv does it. The new method is marked stable since Node.js v24.

import { loadEnvFile } from 'node:process';

// load .env file with default path ('./.env')
loadEnvFile();
// load .env file with a custom path
loadEnvFile('../../.env');

One thing to watch out for, though, is that loadEnvFile() throws if the .env file doesn't exist, which is usually the case in production environments. But that's no problem, and I wrapped it into a small utility when I was removing dotenv from one of my projects.

import { loadEnvFile } from 'node:process';

export function safeLoadEnvFile(): void {
  try {
    loadEnvFile();
  } catch (error) {
    // In prod environments there's usually no `.env` file.
    // Ignore the error thrown if the file doesn't exist.
  }
}

I love seeing Node.js moving forward!

Edit: If you're looking for a more advanced snippet to bring into your projects, François shared an environment-aware way to load .env files.

I've thought that the new light-dark() CSS function can be used as a drop-in replacement for prefers-color-scheme media queries. Today I learned that they don't always behave the same.

Here's how MDN describes the new color function:

The light-dark() CSS <color> function enables setting two colors for a property [...] without needing to encase the theme colors within a prefers-color-scheme media feature query.

If you wonder about light-dark() browser support, here we go.

MDN Compat Data (source)

Browser support info for `light-dark()`

123	123	123	120	120	17.5	17.5	27.0	123

Now, I thought you could replace all your verbose color scheme queries with short light-dark() one-liners.

/* The old way of flipping dark mode styles */
.someElement {
  background: #eee;
  color: #333;
  border-color: #ddd;

  @media (prefers-color-scheme: dark) {
    background: #333;
    color: #eee;
    border-color: #444;
  }
}

/* The new way of flipping dark mode styles */
.someElement {
  background: light-dark(#eee, #333);
  color: light-dark(#333, #eee);
  border-color: light-dark(#ddd, #444);
}

Unfortunately, things aren't that easy.

The first thing to realize is that light-dark() requires a properly set color-scheme. Here's MDN again:

To enable support for the light-dark() color function, the color-scheme must have a value of light dark, usually set on the :root pseudo-class.

Without setting color-scheme: light dark; on :root or a surrounding container, the light-dark() function won't work. Flip your operating system's color theme and you'll see that light-dark() doesn't work below.

[Interactive component: visit the article to see it...]

The prefers-color-scheme query, on the other hand, will react to your operating system's preferences no matter what. This behavior seems strange, but I assume that prefers-color-scheme was introduced way before the color-scheme property was a thing, so that considering color-scheme would have been a breaking change.

However, adding color-scheme: light dark; is quickly done, right?

[Interactive component: visit the article to see it...]

While working on the new Web Weekly site, I implemented a color theme toggle and things got interesting.

The Web Weekly redesign is Tailwind-based and to implement a light and dark mode I added custom color variables to my tailwind.config.ts to avoid placing dark:* classes everywhere.

ts
export default {
  theme: {
    extend: {
      colors: {
        // light / dark styles
        "ld-slate-50":
          "light-dark(oklch(98.4% 0.003 247.858), oklch(12.9% 0.042 264.695))",
        "ld-slate-100":
          "light-dark(oklch(96.8% 0.007 247.896), oklch(20.8% 0.042 265.755))",
        "ld-slate-100/75":
          "light-dark(oklch(96.8% 0.007 247.896 / 0.75), oklch(20.8% 0.042 265.755 / 0.75))",
        // ...
      },
    },
  },
};

This new color palette implements the standard Tailwind colors but uses light-dark() to automatically flip them. ld-slate-100 would be slate-100 in light mode and slate-800 in dark mode. Not gonna lie, I felt very smart when coming up with this idea.

The ld-* colors worked okay-ish until I had to fine-tune my dark mode styles and mix my automatic light-dark() color with dark:* colors using prefers-color-scheme.

My plan was to implement a dark/light mode toggle that changes the general color-scheme value and the rest should "just work", right? light dark would be the default, light should be set in light mode and dark in dark mode.

Turns out, this approach works great for light-dark() however prefers-color-scheme doesn't seem to care about color-scheme values and always relied on the OS settings.

[Interactive component: visit the article to see it...]

light-dark() always reflects the currently set color-scheme. For color-scheme: light dark; it falls back to the operating system settings, it returns the light variant for color-scheme: light; and the dark one for color-scheme: dark;. It does exactly what I expected.

prefers-color-scheme isn't affected by the color-scheme value and always falls back to the operating system's color scheme. Isn't this surprising?

I don't know the exact reasoning here, as mentioned above, it surely must be some backwards compatibility thing. If you know more, reach out and let me know. I'd love to extend this post later.

So, whenever you read somewhere that light-dark() is just a shorter prefers-color-scheme query, be aware this isn't true! If you're dealing with color-scheme-based theming, this statement is fake news...

If you maintain a Node.js library or framework that's consumed by people downstream, you know the pain of introducing breaking changes and deprecating existing functionality. People get mad very quickly and the only solution is to communicate very early that things might change or will disappear in a future version.

I've thought that the only way to communicate future deprecations is to mark methods as deprecated via TSDoc / JSDoc.

/**
 * Returns a string value.
 * @deprecated This function is deprecated and will be removed in a future version.
 * @returns {string} The string 'something'
 */
export const getSomething = () => {
  return 'something'
}

In this case, if someone imports the deprecated getSomething method, the editor (in my case it's VS Code) will make it very clear that they should look into not using the method.

VS Code's crossed out text is very convincing if you ask me but I don't know if every editor displays deprecation warnings as prominently.

If you really want to make sure people see your Node.js deprecation notice, today, I learned that Node.js provides a native deprecate method.

import { deprecate } from "node:util";

/**
 * Returns a string value.
 * @deprecated This function is deprecated and will be removed in a future version.
 * @returns {string} The string 'something'
 */
export const getSomething = deprecate(() => {
  return 'something'
}, 'watch out! something is deprecated!')

And if someone now uses deprecated methods, they will also get notified when they run the code via Node.js.

$ node index.ts

something
(node:21682) DeprecationWarning: watch out! something is deprecated!
(Use `node --trace-deprecation ...` to show where the warning was created)

Sweet!

You've probably seen this SVG effect that people use to animate signatures. If you have an SVG path you can combine stroke-dasharray, stroke-dashoffset and CSS animations/transitions to animate a given SVG path. Here's an example of the effect.

[Interactive component: visit the article to see it...]

The SVG includes a single SVG path that expands when you hover over the SVG. How does this work in detail?

As a first step, you can cut SVG paths into visual pieces with stroke-dasharray. It's important to know that the "drawn pieces" and in-between gaps will have the same length.

Then, after you've chopped your path into pieces, you can move these pieces around the SVG path with stroke-dashoffset.

So, the overall trick is to make the pieces as big as the entire path length to transition from showing a gap (which spans the entire path) to showing a drawn piece next to it.

[Interactive component: visit the article to see it...]

If you played with the demo above, you might have wondered where this magic number (14302) is coming from. 14302 is the overall path length, and you can access it with some JavaScript.

const path = document.querySelector('path');
const pathLength = path.getTotalLength();

With the path length available, you can then write some quick CSS to achieve this effect.

path {
  /* Cut the path into pieces being as long as the path itself */
  stroke-dasharray: 14301;
  /* Move the rendering to the gap */
  stroke-dashoffset: 14301;
  transition: stroke-dashoffset 0.75s ease-in-out;
  
  &:hover {
    /* Transition the offset to show the rendered path piece */
    stroke-dashoffset: 0;
  }
}

And while this approach works just fine, it's a bit cumbersome to always figure out the path length. After reading Josh's wonderful article A Friendly Introduction to SVG, I learned that you can set the path length manually in your SVG using the pathLength attribute!

<svg width="7149" height="1392" viewBox="0 0 7149 1400">
  <path d="M0.640625 ..." pathLength="100" />
</svg>

And with this tiny adjustment, the CSS animation becomes way easier to handle because you can base your animations on the path length of 100.

path {
  /* Cut the path into pieces being as long as the path itself */
  stroke-dasharray: 100;
  /* Move the rendering to the gap */
  stroke-dashoffset: 100;
  transition: stroke-dashoffset 0.75s ease-in-out;
  
  &:hover {
    /* Transition the offset to show the rendered path piece */
    stroke-dashoffset: 0;
  }
}

Isn't this way nicer? I'm a fan!

There's a new CSS property in town: field-sizing. field-sizing: content allows form controls to adjust in size to fit their contents. At the time of writing this property is still in flux in terms of baseline support.

MDN Compat Data (source)

Browser support info for field-sizing

123	123	123	Nö	Nein	26.2	26.2	27.0	123

So far, I've thought the new property is only about expanding textarea elements, but apparently it works for other input elements, too.

[Interactive component: visit the article to see it...]

That's good stuff!

Using proper ARIA landmark roles allows assistive technologies to navigate a page. You probably know about some common ones: main (main), header (banner), footer (contentinfo). But do you know that header and footer don't always get assigned their initial ARIA roles?

Here's an example:

<header>
  "Root" header
</header>
<main>
  <header>
    "Main" header
  </header>
  <footer>
    "Main" footer
  </footer>
</main>
<footer>
  "Root" footer
</footer>

This HTML snippet includes header and footer elements that are a) on the root level and b) included in a main element. If you check the browser's accessibility tools, these elements get different roles assigned.

The header element loses its banner role and depending on the browser gets generic or sectionheader assigned, which has an effect on assistive technologies. Here's Martin in his post "Page headings don't belong in the header":

The header would carry no semantic meaning, so screen reader users would be left wondering where the main page header landmark was.

You can find similar behavior, though not identical, with the footer element.

Footer elements receive varying roles from sectionfooter and generic.

If you look at the "ARIA in HTML" spec, you'll find some answers.

For the header element:

If not a descendant of an article, aside, main, nav or section element, or an element with role=article, complementary, main, navigation or region then role=banner. Otherwise, role=generic.

For the footer element

If not a descendant of an article, aside, main, nav or section element, or an element with role=article, complementary, main, navigation or region then role=contentinfo. Otherwise, role=generic.

But what if you can't change the document structure or really want to have the header element in a sectioning main? If you really must, you can get out the hammer and add a landmark role yourself.

<main>
  <header role="banner">
    "Main" header
  </header>
</main>

I'm not sure how I feel about this, though.

Where does this lead us? You probably shouldn't rely on or use the new sectionheader and sectionfooter roles yet. Here's Luke from Igalia giving some advice:

Browser support needs to improve but AT also won't necessarily understand these roles yet.

It will take some time until browsers have caught up and then still screen readers need to implement the new roles, too. This won't happen until tomorrow.

But generally, whenever you use header or footer elements, make sure to double check the applied ARIA landmark roles and avoid placing the elements in sectioning content like the main element. Otherwise, you might not provide the accessibility benefits you're hoping for.

The two most popular glob utilities (minimatch and glob) are responsible for over 500 million weekly npm downloads. Something so common should be included in the Node core library, right?

Today, I discovered that native "globbing" is included in Node core since v22.17.

The new utility comes in three flavors.

This fsPromise.glob version returns and an AsyncIterator which allows to end the globbing in a for await/of loop early if you have found what you're looking.

Alternatively, use Array.fromAsync if you don't care about breaking out early and want to discover all the files.

import { glob } from 'node:fs/promises';

// Iterate over discovered file paths
for await (const entry of glob('**/*.txt')) {
  console.log(entry);
}

// Await all files paths
const files = await Array.fromAsync(glob('**/*.txt'));
console.log(files);

fs.glob() is callback-based if that's your jam.

import { glob } from 'node:fs';

await glob('**/*.txt', (error, files) => {
  console.log(files);
});

And, of course, there's a synchronous version with fs.globSync(), too.

import { globSync } from 'node:fs';

console.log(globSync('**/*.txt'));

Now, I'm sure there are some minor differences to the popular libraries, but I bet it'll be fine for some quick file-grepping in JavaScript.

I've been reading Josh's post The Big Gotcha With @starting-style and learned a new thing about CSS @keyframes.

Instead of doing specificity math for each built-in style, the browser treats them [the animation styles] as an entirely separate collection of CSS. They get applied first, and any CSS we write, no matter its specificity, will overwrite it.

Granted, I don't use keyframe animations very often, but what CSS collection is Josh talking about? The answer can be found on the MDN docs explaining the CSS cascade.

The cascading algorithm determines what properties to apply to an element in the following order:

1. user-agent (browser) normal
2. user normal
3. author (developer) normal
4. CSS keyframe animations
5. author (developer) !important
6. user !important
7. user-agent (browser) !important
8. CSS transitions

And keyframe animations have a higher precedence than any other "non-important" style. This behavior makes it quite handy to apply entry animations.

[Interactive component: visit the article to see it...]

You can apply a keyframe animation that only defines from styles and can then automatically transition to the other applied properties. This keyframe transition works because keyframe styles are treated higher in the cascade algorithm. Well, today I learned!

If you apply !important styles, this doesn't work for the same cascade algorithm rules.

[Interactive component: visit the article to see it...]

Keyframe animations won't overrule !important styles and slapping more !important properties into your keyframes won't work either.

[Interactive component: visit the article to see it...]

Either way, Josh argues that for the mentioned reasons, @starting-style might be a mistake and the more I think of it, I think he's right.

In growing JavaScript projects it is very common to end up with very long import paths navigating up and down the file tree (../../../src/lib/whatever/index.js). This isn't only terrible to read but can also be hard to refactor if you move files around.

To make things a bit easier, bundlers or the TypeScript compiler allow you to define path aliases (@lib/whatever/index), but I usually try to avoid bundling my Node.js applications to keep the complexity low. Today I learned that Node.js allows you to set path aliases with import maps.

Let's say you have this Node.js code using ESM.

import { getAuthenticatedUser } from "./src/lib/auth/user.js";
import database from "./src/lib/db/index.js";

// more stuff...

While this isn't the worst, the file paths could be way cleaner. To set aliases, head into your package.json and define an imports object.

{
  "imports": {
    "#auth/*": "./src/lib/auth/*.js",
    "#db": "./src/lib/db/index.js"
  }
}

Custom import paths need to start with a # and thanks to these two quick lines you can now shorten any import going into ./src/lib/auth and also directly reference ./src/lib/db/index.js with three characters (#db).

import { getAuthenticatedUser } from "#auth/user";
import database from "#db";

// more stuff...

Sweet! But does it work everywhere? Or is this a new Node.js thing?

Nope, this isn't new. Import maps are supported in Node.js since v14 (we're currently on v22 LTS), so your Node.js environment will probably support them already. Have fun shortening some paths!

Here's Alex blogging about forbidden request headers. Forbidden what? Exactly!

It turns out that when using the fetch API (or if you're old school, XMLHttpRequest) there's a set of headers that you can't specify or overwrite from within JavaScript.

The spec defines three different types of forbidden request headers.

First, all headers in this list are forbidden:

• Accept-Charset
• Accept-Encoding
• Access-Control-Request-Headers
• Access-Control-Request-Method
• Connection
• Content-Length
• Cookie
• Cookie2 (This seems to be a deprecated spec that never went anywhere)
• Date
• DNT
• Expect
• Host
• Keep-Alive
• Origin
• Referer
• Set-Cookie
• TE
• Trailer
• Transfer-Encoding
• Upgrade
• Via

Second, headers starting with proxy- or sec- are also forbidden.

And third, if there's something going on with the parsed values of the headers X-HTTP-Method, X-HTTP-Method-Override, and X-Method-Override header they might be forbidden, too.

Apparently, you can overwrite or at least signal that the initial HTTP method should be a different one? I have so many questions, but I'll leave them for another time.

So, what happens if you try to set a forbidden header?

fetch('https://api.example.com/data', {
  headers: {
    'Content-Length': '100',  // This will be ignored
    'X-Custom-Header': 'This is fine'  // This will be sent
  }
})

Browsers will simply ignore them and maybe, if they're kind, log a warning.

This all makes sense because the spec states that there should be things the user agent remains in control of.

These are forbidden so the user agent remains in full control over them.

This behavior makes total sense to avoid nasty security loopholes. I can imagine that if JavaScript could overwrite every header it would open all kinds of security vulnerability doors.

If you want to dive deeper check out Alex's post, it's a nice one.

I've been a Mac user for a very long time and I think I just learned my new favorite shortcut from this massive post about macOS shortcuts.

Now, English isn't my first language and I still need to look up words daily. Usually, I use Google Translate or Raycast for this, but today I learned the macOS Dictionary app (which I barely use) provides inline help.

You can bring it up with ⌘⌃D (D for dictionary).

And because this functionality comes from an official macOS app, the shortcut works in the browser, PDFs, Slack, etc.

Whoa! I'm amazed. 😱

Side note: someone pointed out that this inline help also shows up when doing a force click on the Mac trackpad, but I have most of the trackpad magic turned off because it drives me nuts.

You probably know our good old friend parseInt and its quirks.

// it ignores whitespace
parseInt("   123 "); // 123

// it ignores leading zeros
parseInt("077"); // 77

// it truncates the decimal part
parseInt("1.9"); // 1

// it parses numbers sometimes with a different base
parseInt(015); // 13
parseInt('0x14'); // 20

I've just read Aleksandr's post and learned about a parseInt superpower.

Apparently, parseInt can parse Emoji numbers correctly!

parseInt('1️⃣'); // 1
parseInt('2️⃣'); // 2
parseInt('3️⃣'); // 3

What? It doesn't make any sense that this works!

And, of course, parseInt can't parse Emoji numbers, but the combination of how Emoji numbers are put together and a parseInt quirk makes it appear as if parseInt could parse Emojis.

I always thought parseInt would try to parse the entire passed-in value, and if it failed, it would return NaN. And this is mostly correct...

parseInt('wat');     // NaN
parseInt('wat', 10); // NaN

... unless the value you want to parse starts with a numeric value like the number Emojis (1️⃣ = 1 + more code points).

parseInt('1w');     // 1
parseInt('1w', 10); // 1

parseInt('1.5w');     // 1
parseInt('1.5w', 10); // 1

If your value starts with an unparsable character, you'll be back at NaN.

parseInt('a1w');     // NaN
parseInt('a1w', 10); // NaN

I must say I find this wild and confusing, but I guess this behavior was put in there to parse numbers with units more easily.

parseInt('12€'); // 12

However, JavaScript never holds back with a twist. Philipp pointed out that the Number() constructor behaves differently.

Number('1️⃣');   // NaN
Number('1w');   // NaN
Number('1.5w'); // NaN
Number('a1w');  // NaN
Number('12€')   // NaN

Number('1.2'); // 1.2

Well, it's good to know about all these quirks!

Let's say you have this TypeScript type.

ts
type Example = {
  // Method shorthand syntax (should be avoided)
  method(x: string | number): void
  // Function (or object property) syntax
  fn: (x: string | number) => void;
};

You might expect the function types method and fn to behave exactly the same, right? The only difference is that one is defined in method shorthand, whereas the other is defined in function syntax. Both accept an x param that could either be a string or a number

But now check this out.

ts
function fn(x: string) { /* ... */ }
 
const example: Example = {
  // this is "fine" (but shouldn't be)...
  method: fn,
  // this is erroring correctly...
  fn: fn,
Type '(x: string) => void' is not assignable to type '(x: string | number) => void'.
  Types of parameters 'x' and 'x' are incompatible.
    Type 'string | number' is not assignable to type 'string'.
      Type 'number' is not assignable to type 'string'.2322Type '(x: string) => void' is not assignable to type '(x: string | number) => void'.
  Types of parameters 'x' and 'x' are incompatible.
    Type 'string | number' is not assignable to type 'string'.
      Type 'number' is not assignable to type 'string'.
};

If you create an example object whose properties don't match the Example type, only the function syntax will detect the type mismatch. What's going on?

Apparently, there's a strictFunctionTypes TypeScript config option (part of TypeScript's strict config) that only works for the function syntax for legacy reasons.

During development of this feature, we discovered a large number of inherently unsafe class hierarchies, including some in the DOM. Because of this, the setting only applies to functions written in function syntax, not to those in method syntax:

The TypeScript devs purposefully turned off a type check feature for legacy reasons. Wild!

It's good to avoid the method syntax altogether and if you use TypeScript ESLint, there's a rule for it.

I just learned that executing r in my terminal, reruns the previous command. #wat

r is a built-in shell command in my zsh setup.

$ which r
r: shell built-in command

If you check all the built-in zsh commands with man zshbuiltins, you'll receive the unhelpful information that r command is the same as fc -e -.

r — Same as fc -e -

Alright, I'll bite, what's fc?

fc is included in the zsh built-ins, too. The fc command lets you display, edit or execute commands from the shell history, but unfortunately, the zsh man pages fail to answer what fc actually stands for.

Some folks say fc stands for "fix command" whereas others advocate for "find command". Both definitions make sense, but I didn't see it written in the zsh / bash man pages.

fc is handy when juggling long and complicated shell magic that requires editing and rerunning.

But what's up with this r command standing for fc -e -?

The quick answer: r uses fc to rerun the previously executed command without the option to change it.

$ echo "hello world"
hello world

$ r
echo "hello world"
hello world

You can also narrow and search the command to run by calling r with additional arguments. For example, r ls will rerun the previously run ls command.

$ ls -lah
...

$ # some more commands
$ # some more commands
$ # some more commands

$ r ls
ls -lah
...

But where is this execution behavior documented? Honestly, I've no clue...

According to the fc documentation, the -e flag allows you to define the used editor before rerunning the command, but -e seems to unlock some superpowers when paired with -. Unfortunately, I couldn't find this behavior described anywhere.

However, r is a very convenient way to rerun a command without reaching for the arrow keys!

If you have more insights, please let me know.

Is it just me, or are TypeScript conditional types and the extends keyword kinda scary?

ts
// What is going on? 😅
type Something<T> = T extends number ? never : T;

I've just read Dr. Axel's "Conditional types in TypeScript" and some things finally clicked for me.

Let's say we have a union type containing multiple strings.

ts
type AllColors = "Black" | "White" | "Orange" | "Red" | "Blue" | "Yellow" | "Gray";

Some people don't consider black, white and gray as colors. How could you now iterate over the union type and get these "noncolors" out of the AllColors type?

ts
// Iterate of the types included in `AllColors`.
//
// If type `T` does not extend `R` apply the `never` type.
// `never` will remove `T` from the resulting union type.
type Remove<T, R> = T extends R ? never : T;
 
// Remove "Black" and "White" from "AllColors" union type.
type RealColors = Remove<AllColors, "Black" | "White" | "Gray">;
         
type RealColors = "Orange" | "Red" | "Blue" | "Yellow"

Using conditional types, you can iterate over and filter union types. If you return never, it will be excluded from the resulting union type.

That's pretty cool, but you can use conditional types also to iterate over a union type and map the resulting types.

In this example, the strings are prefixed with String: .

ts
type Random = "Joo" | "Foo" | 123 | 234;
 
// Iterate of the types included in `Random`.
//
// If type `T` is of type `string` prefix it.
type Prefix<T> = T extends string ? `String: ${T}` : T;
type MappedTypes = Prefix<Random>;
         
type MappedTypes = 123 | 234 | "String: Joo" | "String: Foo"

Or, if we take the color example, we could also iterate and append (noColor) to Black, White and Gray.

ts
type AllColors = "Black" | "White" | "Orange" | "Red" | "Blue" | "Yellow" | "Gray";
 
// Iterate of the types included in `AllColors`.
//
// If type `T` is of type `string` and `T` is of type `R`
// append parentheses to the string type.
type Suffix<T, R> = 
  T extends string 
    ? T extends R ? `${T} (no color)` : T
    : T;
type MappedColors = Suffix<AllColors, "Black" | "White" | "Gray">;
          
type MappedColors = "Orange" | "Red" | "Blue" | "Yellow" | "Black (no color)" | "White (no color)" | "Gray (no color)"

Granted, the nested ternary isn't pretty, but it seems to be the only way to include two conditions to TypeScript's conditional types.

And as a last trick: if your union type only includes strings, you can spare all this extends dance and use template literal types.

ts
type AllColors = "Black" | "White" | "Orange" | "Red" | "Blue" | "Yellow" | "Gray";
type AllPrefixedColors = `Color: ${AllColors}`;
            
type AllPrefixedColors = "Color: Black" | "Color: White" | "Color: Orange" | "Color: Red" | "Color: Blue" | "Color: Yellow" | "Color: Gray"

Good stuff!

When you commit things in Git via the CLI, you'll be greeted with something that looks like this:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch main
# Changes to be committed:
#       new file:   ...

You'll write your commit message on the first line, hit save, close the file, and go on with your nerdy day.

The lines starting with a # will be ignored and not included in your commit data. Most lines in this boilerplate message start with a # and should enable you to make a good commit. It's good to know which files will be included and double-check that you're on the correct branch, right?

But what makes a good commit?

Creating good commits can be complicated because every project/team has its own rules. Some bet on Gitmoji. Some want you to include a ticket number. Others might prefer lengthy explanations of the changes to generate an automated changelog.

Today I learned that Git supports commit message templates to make your life easier if you're facing specific commit requirements.

Run this command...

git config --global commit.template ~/.gitmessage

... to add this line to your general .gitconfig file...

[commit]
  template = ~/.gitmessage

... and create a ~/.gitmessage file...

# Yo, waz up! Dude, remember to follow these conventions (👇) , okay?
#
# 1. do this!
# 2. do that!
# ...

... that contains your custom commit template.

Now, you'll be greeted with your custom message when you make a commit.

Pretty sweet!

Setting a global commit template isn't very user friendly. It'd be great to use Git's includeIf to set up project-dependent commit templates somehow, but I'll leave this for another day.

How do you deal with TypeScript when (for whatever reason) types are mixed up, everything's full of squigglies, but you're sure you want to ignore this one particular TypeScript error?

Let's look at a very simplified example; let's say you have a method taking in a string argument.

ts
function logify(msg: string) {
  console.log(`Msg: ${msg}!`);
}

But you want to use the logify function with a number type. Of course, TypeScript won't be happy about you using logify with the wrong argument types. Still, you're 100% certain you want to call the function with a number type.

ts
logify(123);
Argument of type 'number' is not assignable to parameter of type 'string'.2345Argument of type 'number' is not assignable to parameter of type 'string'.

What can you do?

You can bring in your friends @ts-ignore and @ts-expect-error to silence TypeScript.

ts
// @ts-ignore
logify(123);
 
// @ts-expect-error
logify(123);

Both, @ts-ignore and @ts-expect-error, will make TypeScript ignore the type error happening on the following line. But which one should you use?

Generally, it's recommended to go for @ts-expect-error because it will lead to a TypeScript error when the following line isn't erroring anymore.

For example, it could be that the logify types will be changed to also accept numbers. Then, @ts-expect-error will let you know that you can remove it.

ts
// Let's allow number types... 👇
function logify(msg: string | number) {
  console.log(`Msg: ${msg}!`);
}
 
// @ts-ignore
logify(123);
 
// @ts-expect-error
Unused '@ts-expect-error' directive.2578Unused '@ts-expect-error' directive.
logify(123);

The difference between the two comment directives is that @ts-expect-error forces you to clean up later. @ts-expect-error will let you know when there's no TypeScript error to silence and when it has become useless. @ts-ignore will stay put and sit silently wherever you placed it.

But whatever you choose, remember that you can extend @ts-comments as well. So, when you place them in your codebase, do yourself a favor and document why they're there.

ts
// @ts-ignore: `logify` should also allow numbers.
logify(123);
 
// @ts-expect-error: `logify` should also allow numbers.
logify(123);

That's it for today. ✌️

Back in the days, I used to joke about people using spreadsheets for everything. Especially in larger companies; whatever can be placed in a spreadsheet will eventually land in a spreadsheet.

Thanks to Alex, today I learned, that some spreadsheet tools (Google Sheets and Excel) let us load images, too.

=IMAGE("https://www.google.com/images/srpr/logo3w.png")

I think this is pretty wild.

But it might make sense to enrich sheets with images in product listings and similar things. 🤷

You probably know that you can spin up Playwright's UI mode with npx playwright test --ui and rerun your tests with the watch mode.

It's a handy feature when you're developing your tests while still being in the try-and-error phase. Especially when I'm working on quick tests, I miss the quick feedback loop of CLI watch mode, which doesn't seem to be implemented. Or is it?

I just discovered a CLI watch mode topic GitHub issue.

microsoft/playwright #21960 OPEN

[Feature] "Headless" CLI Watch Mode

RichiCoder1 opened it Mar 24 2023

Turns out, people are asking for a CLI watch mode, and a first version is implemented, and you can use it by setting an environment variable.

PWTEST_WATCH=1 npx playwright test

I played around with it for a minute and will definitely use the hack out of it.

But be aware: the current implementation is experimental, and it's there to gather feedback from the community. The feature might break or even disappear, but if you have feedback or want to give a thumbs-up, head over to the GitHub issue.

I'd love to see this becoming a real --watch mode, though.