Just let TypeScript do its thing

It is a well known fact that compile-time errors during development are easier and cheaper to catch than runtime ones in production. Unfortunately people keep forgetting that simple fact. Let me tell you a little story about AWS Lambda hiccup, and how it could easily be avoided.

A developer wrote a simple Lambda function in TypeScript that would receive a parameter of the following type:

interface Notification {
    slack?: {
        notify: boolean
    github?: {
        notify: boolean

The logic is simple – if slack.notify is true – send slack notification. If github.notify is true – send github commit status notification. The function deployed without issues, and it does send slack notifications. There is one problem: often it would send the same slack notification 3 times in a row. Continue reading →

Scan standalone CDK constructs for misconfiguration

Vulnerability scanners like checkov have become a de facto standard for scanning IaC for possible misconfigurations. They can scan terraform configs, AWS CloudFormation templates, even – in a sense – CDK stacks, because they synthesize into CloudFormation templates that can be scanned.

In order to produce synthesized templates from stacks you have to have a full-blown CDK application. But what if you’re developing a standalone CDK construct as a library, to be used as a dependency in a CDK app? There is a way to scan it for vulnerabilities as well.
Continue reading →

Override private methods in TypeScript

First things first: a word of caution – do this only if you absolutely have to. TypeScript has these checks for a reason, and probably in 99% of the cases you should respect and abide these restrictions. But if your scenario falls within the 1% where you must in a subclass override a private method of a superclass – this post shows a way to do this.

Let’s say we have a class that defines a generic starship, and what happens to it when it’s hit by a weapon:

type Hit = 'phaser' | 'antimatter spread' | 'photon torpedo'

class Starship {
    private totalDamage: number;

    constructor(private shipName: string) {
        this.totalDamage = 0;

    private addDamage(damage: number) {
        this.totalDamage += damage;

    public isHitBy(hit: Hit) {
        console.log(`${this.shipName} is hit by ${hit}!`)

        switch(hit) {
            case 'phaser':
            case 'antimatter spread':
            case 'photon torpedo':

You can create your own class of starship based on this generic class, then build a ship of the new class, and simulate it being hit by a weapon:

class Galaxy extends Starship {
    constructor(name: string) {

const enterprise = new Galaxy('Enterprise');
enterprise.isHitBy('photon torpedo');


"Enterprise is hit by photon torpedo!"

This is fine, but as you’ve seen the base class has a secret feature to calculate damage inflicted by the weapon. It is secret, because it’s defined by a private method, and is not exposed to derived classes. But, like Kirk in Kobayashi Maru, you want to break the rules, and have this forbidden knowledge. Continue reading →

Reverse values into variables in tmplr

tmplr is a versatile templating tool that lets you quickly create a repository from a template customized for your needs. By running a recipe it can substitute placeholder variables with your own values making the repository truly your own. For example it can update package.json with dynamic values from git context. It can do much more, put for the purpose of this post we will concentrate on literal values in code files.

Let’s say you have a JavaScript code that performs some AWS SDK/CDK actions, and it requires AWS account IDs – for dev and prod deployment. In a regular repo you would define config.js something like this:

const awsAccounts = {
   dev: '1234567890',
   prod: '0987654321'

But if we’re building a template repo – we don’t want to hardcode those values. Instead we could use tmplr placeholder variables:

const awsAccounts = {
   dev: '{{ tmplr.dev_account_id }}',
   prod: '{{ tmplr.prod_account_id }}'

Save this file as config.tmplr.js – it becomes our template. A user of your template then can create a tmplr recipe:

  - read: dev_account_id
    eval: '1234567890'
  - read: prod_account_id
    eval: '0987654321'
  - copy: config.tmplr.js
    to: config.js

then save this it into .tmplr.yml file into repo root, and run tmplr cli command – it will create config.js file from config.tmplr.js substituting variables for values from the recipe.

It works great, but there is a problem. Continue reading →

Synthesize only stacks you need in CDK

CDK documentation states that if you supply stack name(s) to CLI commands like cdk synth, cdk list or cdk deploy – it will synthesize only the stacks you requested. But in reality this is not the case, CDK will always synthesize all stacks – and it may lead to unintended consequences.

Let’s say you have following stack declarations in your lib/my-stacks.ts code:

import * as cdk from 'aws-cdk-lib';

export class Stack1 extends cdk.Stack {};
export class Stack2 extends cdk.Stack {};
export class AnotherStack extends cdk.Stack {};
export class YerAnotherStack extends cdk.Stack {};

And in your app’s entry point bin/my-stacks.ts you instantiate those stacks:

import * as cdk from 'aws-cdk-lib';
import * as stacks from '../lib/my-stacks'

const app = new cdk.App();

new stacks.Stack1(app, "Stack1");
new stacks.Stack2(app, "Stack2");
new stacks.AnotherStack(app, "AnotherStack");
new stacks.YerAnotherStack(app, "YetAnotherStack");

And then issue a CLI command to synthesize stacks, but you only want to synthesize “Stack1” and “AnotherStack”:

cdk synth Stack1 AnotherStack

The command output would have you believe that only 2 stacks were synthesized:

Successfully synthesized to ./cdk.out
Supply a stack id (AnotherStack, Stack1) to display its template.

Continue reading →

Enable ActivityPub Plugin on Bitnami WordPress instance with LetsEncrypt

ActivityPub plugin is a very cool piece of WordPress addition. With this plugin installed users of Mastodon and other such federated platforms that support ActivityPub can follow your blog as if it were another instance on the Fediverse.

Unfortunately if you run a Bitnami instance of WordPress (for example one provided by AWS LightSail with LetsEncrypt service providing a TLS certificate for you site – you may encounter an incompatibility issue. LetsEncrypt uses /.well-known/acme-challenge path on your site for certificate validation, but ActivityPub plugin uses /.well-known/webfinger path to return relevant profile information. It conflicts with LetsEncrypt and the WebFinger path returns “404 – not found”.

Fortunately there is an easy fix. SSH to your server, locate file /opt/bitnami/apps/letsencrypt/conf/httpd-app.conf, and add highlighted lines to it:

<Directory "/opt/bitnami/apps/letsencrypt/.well-known">
    Options +MultiViews
    AllowOverride None
    <IfVersion < 2.3 >
        Order allow,deny
        Allow from all
    <IfVersion >= 2.3>
        Require all granted
    RewriteEngine On
    RewriteBase /.well-known/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ /index.php?well_known_path=$1 [QSA,L]

After that Webfinger starts returning correct profile information, and your site can be found on the Fediverse.

Wait for AWS region to become available

AWS CLI has a nifty useful command to enable/opt-in a region on your account – account enable-region e.g.

aws account enable-region --region-name af-south-1

There is a caveat though – this command only begins to enable the region. The process could take a while, but the command exits right away. But what if you need do something with the region when it becomes available? Say you’re running a script and you need to bootstrap the region when its enabled. You need some way to wait for the enablement to finish. Luckily there is another AWS CLI command that lets you check the status of the region – ec2 describe-regions, e.g.

aws ec2 describe-regions --region-names af-south-1

One of the properties it return is whether the region is enabled/opted-in or not. Combining this with a little of bash magic – we can come up with a waiting routine:

aws account enable-region --region-name af-south-1
until [ "$state" = "opted-in" ]
   echo Waiting for af-south-1...
   sleep 5
   state=$(aws ec2 describe-regions --region-names af-south-1 --query "Regions[0].OptInStatus" --output text)

Here on the Line 1 we execute command that initiates enabling region. And the rest is a loop: wait 5 seconds, and check the status of the region. Loop exits when the status becomes “opted-in”. At this point we know that the region has been enabled, and can proceed with using it.

CDK pipeline won’t restart after mutation.

CDK Pipeline is a clever construct that makes continuously deploying your application and infrastructure super easy. The pipeline even has the ability to update itself or “mutate” if your commits include changes to the pipeline itself. This behavior is controlled by selfMutation property of the pipeline constructor and is true by default. Once the pipeline updates itself – it also restarts itself, so that new changes can take effect.

But if you create your CDK pipeline with regular AWS Pipeline as a base e.g.

const rawPipeline = new Pipeline(this, 'RawPipeline', {

const pipeline = new CodePipeline(this, 'Pipeline', {
   codePipeline: rawPipeline,

suddenly the pipeline won’t auto-restart after the mutation. What is happening? Continue reading →

Share node_modules between CDK CodeBuildSteps

CDK makes it pretty easy and straightforward to create CodePipelines – define the pipeline, add build steps as needed, add deployment stages and you’re done. But imagine a scenario where you install Node dependencies in one step and then need to run some NPM scripts in another down the line. In order to avoid reinstalling the dependencies every time you can pass output of one step as an input of another:

const installStep = new CodeBuildStep("install-step", {
   input: sourceStep,
   commands: ["npm ci"],
   primaryOutputDirectory: ".",

const testStep = new CodeBuildStep("test-step", {
   input: installStep,
   commands: ["npm run test"],
   primaryOutputDirectory: ".",

Passing output of the installStep as input of the testStep copies everything created in the installStep – files, directory structure – including all dependencies installed into node_modules folder to the testStep, so any npm command in theory should work. But in reality they’d fail, telling you that some module or other is not found. The reason is that in addition to installing dependencies npm ci command also creates symlinks between some of them. Copying files from one step to another loses those symlinks. In order to rebuild them you need to run npm rebuild before running any npm commands in the consecutive steps. So the test step becomes

const testStep = new CodeBuildStep("test-step", {
   input: installStep,
   commands: ["npm rebuild", "npm run test"],
   primaryOutputDirectory: ".",

And this will throw no errors.

Easily verify yourself on Mastodon with GitHub

Mastodon unlike Twitter doesn’t have official (or paid, thanks Elon Musk) verification badge for account profile, but it does offer a way to verify yourself – by placing following link tag into HTML of a website/page you own (your blog for example):

<a rel="me" href="https://your.instance/@YourHandle">Mastodon</a>

where “your.instance” and “@YourHandle” are the Mastodon server you use and your profile handle respectfully. But what if you want to verify yourself with your GitHub profile? An ideal place would be something like a README.md file. Unfortunately every link placed into a markdown file automatically gets rel="nofollow", so it’s a no-go. But there is a way to do this. Continue reading →