bsitruk

TS Lazy Conditional Type Evaluation

Below is a five-line “playground-size” demo that lets you watch the conditional type stay in its unevaluated form inside a generic function and collapse as soon as you call the function with a concrete argument.

// 1 ─ a tiny conditional type
type Kind<T> = T extends string ? "str" : "other";

bsitruk

TSConfig customConditions & Conditional Exports

Below is a practical, end-to-end guide to **`compilerOptions.customConditions`** in *tsconfig.json*—what it is, when to reach for it, and how to wire everything up so that your editor, the TypeScript compiler, your bundler, and Node itself all resolve the same files.

---

1. What customConditions actually does

customConditions lets you tell the TypeScript module resolver to recognise extra [conditional-export “conditions”] beyond the built-ins (import, require, node, default, etc.). At compile-time, tsc will use those additional keys whenever it looks at a package’s "exports" or "imports" map, exactly the same way Node or modern bundlers would at run-time.([typescriptlang.org][1])

bsitruk

Node - Library logging

When building a node.js library, what's the recommend way to provide logs to users of the library ?

Below is the approach that most mature Node.js packages follow today, together with links so you can dive deeper.

---

bsitruk

Prompt

How to verify the identity of the publisher of a brew cask ?

To verify the identity of the publisher of a Homebrew cask (macOS application distributed via Homebrew), you can follow these steps:

---

1. Check the Cask Source and Maintainer

Each Homebrew cask is maintained in a GitHub repository (typically Homebrew/homebrew-cask):

bsitruk

Serialization and Parsing Dates in JS

1. Agree on the “over-the-wire” shape first

Concern	Recommended format	Why
Dates	ISO-8601 UTC string (2025-06-18T12:34:56.789Z)	Human-readable, sortable, handled natively by every major client.
BigInt	String	Avoids loss of precision in JS JSON.
Binary	Base-64 string (or separate download URL)	Plays nicely with text-only transports.

bsitruk

REST API - OpenAPI Error Response

#api#best-practice

 When writing the OpenAPI specs of an API, which error case should I document in the "response" section ? 

In OpenAPI you only need to describe the responses that the client can realistically expect and act on for a given operation. The spec itself clarifies that the document

“is not necessarily expected to cover all HTTP response codes … however, it is expected to cover a successful operation response and any known errors.” (swagger.io)

bsitruk

#!/bin/bash

# Check for correct number of arguments
if [ "$#" -ne 2 ]; then
    echo "Usage: $0 <PID> <Label>"
    exit 1
fi

PID=$1
LABEL=$2

bsitruk

#!/bin/bash

# Function to purge a queue
purge_queue() {
    queue_name="$1"
    echo "Purging queue: $queue_name"
    docker exec CONTAINER_NAME rabbitmqadmin -u USER -p PWD -H 0.0.0.0 -P MANAGEMENT_PORT purge queue name="$queue_name" > /dev/null
}

# Fetch all queues

bsitruk

https://stackoverflow.com/questions/22944631/how-to-get-the-ip-address-of-the-docker-host-from-inside-a-docker-container

docker run -it --rm alpine nslookup host.docker.internal

bsitruk

#!/usr/bin/env zx

# usage
#./keys-to-enum.mjs "{                                                                                                                                                                                                                                                                                           220ms  Thu Aug 25 11:04:52 2022
#    attributeName,
#    fieldName,
#    fullyQualifiedName,
#    attributeType,
#    scannerTypeGroup,
#  }: GetRecordFindingsDto"