Skip to main content

TypeScript "No overload matches this call."

· 15 min read

This is normally an easy problem to fix. However, when it isn't easily fixed, trying to find the solution is difficult because the cause is typically not obvious.


This example here is one manifestation of such problems seen with TypeScript. Here, the problem occurs when FormData is used together with Object.fromEntries. E.g.

const form = as HTMLFormElement;
const formData = new FormData(form);
const data = Object.fromEntries(formData);

The IDE shows a wriggly line on formData with the following message:

No overload matches this call.
Overload 1 of 2, '(entries: Iterable<readonly [PropertyKey, any]>): { [k: string]: any; }', gave the following error.
Argument of type 'FormData' is not assignable to parameter of type 'Iterable<readonly [PropertyKey, any]>'.
Property '[Symbol.iterator]' is missing in type 'FormData' but required in type 'Iterable<readonly [PropertyKey, any]>'

No overload matches this call

Two things to check:

  1. Ensure that in tsconfig.json, the lib option contains minimally these two values in the array: DOM and DOM.Iterable (case-insensitive).
  2. If the tsconfig.json file contains the references option, check the lib option in the locations specified under references as well.

Coding conventions

· 5 min read

This is another one of those things that every developer has an opinion of. Can't blame them us really. As much as programming is science, it is also an art. And artists have their own temperaments.

Regardless, unlike artists, developers have to work as a team. That means that they have to follow the team's conventions regardless of their preferences.

Many conventions can now be easily enforced via configurations settings, thanks to the ubiquity of VS Code and, to a lesser extent, Prettier.

This article looks at the easy steps we can take to enforce coding conventions easily for a Next.js project.

Git branching strategy

· 5 min read

I'm preparing a set of materials for a batch of interns whom I will be mentoring for a software development project.

One of the things that they will be doing is to check out an existing codebase to work on. To do that, they need to know Git.

I'm quite certain that the basics of checking in and out code is no problem for them if they have any Github profiles. However, every organization has its own conventions and requirements when it comes to maintenance of their codebases. This post documents my preferences in code maintenance.

Node.js error code `ERR_OSSL_EVP_UNSUPPORTED`

· 2 min read



Error in Node.js output

Error: error:0308010C:digital envelope routines::unsupported

Easiest solution

Create a .npmrc file in the root of the project (same location as your package.json file) with following contents:


TypeScript object types with optional and minimally required properties

· 3 min read


// Solution 1
type LabelEntry = { label: string };
type ImageEntry = { image: string };
type Entry = LabelEntry | ImageEntry;

// Solution 2
type Entry = Record<'label' & 'image', string>;

An object type that I find myself creating very frequently is one that has one or all of several properties. For example, I can create an entry with a text label, one with an image, or one with both:

Auto-increment field with Prisma

· 2 min read

SELECT setval(pg_get_serial_sequence(&#39;tablename&#39;, &#39;id&#39;), coalesce(max(id)+1, 1), false) FROM &quot;tablename&quot;;

This post is a knowledgebase article on Prisma with PostgreSQL.

The typical model in a Prisma schema has an id field that auto-increments:

model User {
id Int @id @default(autoincrement())
name String

The following is working (most of the time) code that inserts a new entry:

data: { name: 'Some User' },

However, the following error may occur:

Unique constraint failed on the fields: (id)

This is baffling - if the field auto-increments, how can the unique constraint be violated?

Docusaurus with Google Authentication

· 5 min read

With a little bit of programming, your site made by Docusaurus can be modified to be accessible only to users signed in to Google.

The source material came from this article by Thomasdevshare. His article describes a similar authentication scheme for Docusaurus with Firebase as the identity provider whereas this article describes the same approach using Google API directly.