DEV Community: Alvin Bellero

📦 I Built 3 Astro Integrations and Shipped Them to npm — Here's What They Do

Alvin Bellero — Sat, 28 Mar 2026 02:23:32 +0000

I've been building with Astro for a while now, and the same pain points kept showing up across projects. I got tired of patching around them and just built integrations instead.

Three packages. All on npm. All open source.

🎯 What's an Astro Integration, anyway?

If you've never built one, an Astro Integration is a package that hooks into Astro's build lifecycle or dev toolbar. You return a name and a hooks object, and Astro calls your callbacks at the right moments.

export default function myIntegration(): AstroIntegration {
  return {
    name: 'my-integration',
    hooks: {
      'astro:build:done': ({ pages }) => {
        // runs after build
      }
    }
  }
}

That's basically it. It's how @astrojs/react, Tailwind, Partytown, and most of the ecosystem slot into your config without you wiring anything up yourself.

📦 `@shiftescape/astro-bundle-budget`

You build your site, ship it, and two weeks later someone notices a page is pulling in 400KB of JS. No warnings. No CI failure. Just a slow page and a mild sense of shame.

This integration hooks into astro:build:done, reads the output, and compares your JS/CSS sizes against budgets you set. Exceed them? Build fails.

import bundleBudget from '@shiftescape/astro-bundle-budget';

export default defineConfig({
  integrations: [
    bundleBudget({
      budgets: [
        { type: 'js', budget: 100 },  // 100KB JS max
        { type: 'css', budget: 50 }   // 50KB CSS max
      ]
    })
  ]
});

Set it once, forget about it. The pipeline tells you when something bloats.

📥 npm · source

🔍 `@shiftescape/astro-env-inspector`

You've got env vars spread across .env, .env.local, .env.production. You're debugging something weird and you genuinely don't know which value Astro is actually reading or if the variable is even loaded at all.

This adds a panel to the Astro Dev Toolbar. All your env vars, grouped, masked by default, searchable. Dev only and nothing touches your production build.

import envInspector from '@shiftescape/astro-env-inspector';

export default defineConfig({
  integrations: [envInspector()]
});

Beats staring at console.log(import.meta.env) output and trying to remember which file overrides which.

📥 npm · source

🗺️ `@shiftescape/astro-toolbar-routes`

Once a project gets past a dozen pages, you're either memorizing routes or digging through src/pages/ every time. Neither is fun.

This puts a route map in the dev toolbar. Every page in your project, grouped, searchable, clickable. It reads your file-based routes at build time and lists them out.

import toolbarRoutes from '@shiftescape/astro-toolbar-routes';

export default defineConfig({
  integrations: [toolbarRoutes()]
});

Click a route, go there. That's the whole thing.

📥 npm · source

Using all three together

npm install @shiftescape/astro-bundle-budget @shiftescape/astro-env-inspector @shiftescape/astro-toolbar-routes

// astro.config.mjs
import { defineConfig } from 'astro/config';
import bundleBudget from '@shiftescape/astro-bundle-budget';
import envInspector from '@shiftescape/astro-env-inspector';
import toolbarRoutes from '@shiftescape/astro-toolbar-routes';

export default defineConfig({
  integrations: [
    bundleBudget({ budgets: [{ type: 'js', budget: 100 }] }),
    envInspector(),
    toolbarRoutes()
  ]
});

The toolbar panels are dev-only. The budget check runs at build time and exits non-zero on failure, so CI picks it up without any extra config.

What I Learned Building These

A few things stood out while building these integrations:

The Astro Integration API is genuinely pleasant to work with. The lifecycle hooks are well-named and the docs are thorough. The hardest part is usually understanding exactly which hook fires when but after building a couple integrations you get a feel for it.

The Dev Toolbar API opens up a lot. Being able to inject custom UI panels into the development browser experience is really powerful. Two of these three integrations live in the toolbar, and the API for building toolbar apps is surprisingly straightforward.

Monorepo setup with npm workspaces is worth the upfront investment. Having a single demo/ project that uses all three integrations locally made testing so much easier. I can build a package, start the demo, and see everything working together without publishing first.

What's Next

All three are at v0.1.x — functional and tested, but still early. There's a lot more I want to do with each of them

If any of these save you some time, a ⭐ on GitHub goes a long way!

Built with the Astro Integration API and listed in the Astro Integrations Library.

🌟 Extensions Dump: Key Tracer!

Alvin Bellero — Mon, 09 Mar 2026 00:15:46 +0000

Hey there, developers! 👋

Back with another Extensions Dump — where I spotlight the VSCode extensions I have been building and why they exist in the first place.

This one is a throwback. I built Key Tracer a while back, quietly published it, and never really gave it the introduction it deserved. So here we are. Let me fix that. 😄

🔍 Key Tracer: Never Lose Your Place in a JSON File Again

If you have ever worked with a deeply nested JSON file — config files, API responses, translation files, massive package.json schemas — you know the pain.

You are staring at a value buried five levels deep and you need to know its exact key path. So you squint. You mentally count the brackets. You scroll up and down. You get it wrong the first time. You try again.

Key Tracer makes that entire experience disappear.

Just hover over any JSON key and the full path shows up instantly. One click and it is in your clipboard. Done.

👉 Key Tracer on VSCode Marketplace

✨ What It Does

Given a JSON file like this:

{
  "app": {
    "settings": {
      "theme": {
        "color": "indigo"
      }
    }
  }
}

Hover over "color" and you get:

Full Path: app.settings.theme.color  [Copy Path]

Click Copy Path and app.settings.theme.color lands straight in your clipboard. No manual typing. No counting brackets. No mistakes.

🚀 Features

🔍 Hover to reveal — shows the full dot notation path of any JSON key instantly
📋 One-click copy — copy the full path to clipboard right from the hover tooltip
⚙️ Custom delimiter — not a fan of dots? Change the separator to /, ->, ::, or whatever fits your project
🎯 Deep nesting? No problem — accurately resolves paths no matter how many levels in you go
🧪 Comprehensive test coverage — built with Mocha and a custom VS Code API mock so it actually behaves

📦 Installation

Two ways to get it:

Option 1 — VS Code Quick Open:

Ctrl+P

Then paste:

ext install AlvinJamesBellero.key-tracer

Option 2 — Extensions panel:

Open Extensions (Cmd+Shift+X or Ctrl+Shift+X)
Search for Key Tracer
Hit Install
Open any JSON file and start hovering 🎉

📖 Key Tracer on the VS Code Marketplace

⚙️ Configuring the Delimiter

By default Key Tracer uses a dot . as the path separator. But if your project uses a different convention, you can change it:

Open Settings (Cmd+, or Ctrl+,)
Search for Key Tracer
Update the Delimiter field to whatever you need

So if you prefer parent/child/target over parent.child.target, you are covered.

💡 When Does This Actually Help?

More than you would think. Here are the situations where I reach for it constantly:

i18n / translation files — these get deeply nested fast. Knowing the exact key path when referencing it in your component matters.

API response debugging — pasting a large JSON response into VS Code and needing to reference a specific nested field path in your code.

Config files — environment configs, feature flag configs, anything with deeply layered structure.

Sending paths to a teammate — "hey can you check app.settings.theme.color?" is a lot cleaner than "it is like... four levels in, under settings, then theme."

🚀 Give It a Try

Key Tracer is free, lightweight, and does exactly one thing well. If you spend any meaningful time in JSON files, it will save you a few mental cycles every single day. Those add up.

Install it, hover over something deeply nested, and let me know what you think. Feedback, feature ideas, and bug reports all go straight to the GitHub repo.

And if it saves you from squinting at brackets at 2am, a ⭐ on the marketplace goes a long way. 😄

👉 Install Key Tracer — marketplace.visualstudio.com

🧠 TypeScript: Type vs Interface — Stop Guessing, Start Knowing

Alvin Bellero — Mon, 09 Mar 2026 00:11:37 +0000

If you have written TypeScript for more than a week, someone has asked you this question. Or you have asked it yourself while staring at a blank file wondering why the language gives you two ways to do what looks like the same thing.

Should I use type or interface?

The Stack Overflow answers are all over the place. The blog posts are mostly outdated. The official docs say "use interface by default" and then immediately show you a dozen things interface cannot do. And your senior colleague says "we just use types for everything" while the other senior colleague says "always interfaces for objects, types for everything else."

Both of them are right. Both of them are incomplete. Let me give you the full picture.

📌 This article is written against TypeScript 5.7 (the current stable release as of early 2026). TypeScript 6.0 is in beta as the final JavaScript-based release, and TypeScript 7 (rewritten in Go) is in active preview. Notes on what changes with 7 are included where relevant.

📖 TypeScript Blog — devblogs.microsoft.com

First, What Do They Actually Do?

Both type and interface let you describe the shape of a value. In their most basic form, they look almost identical.

// With interface
interface User {
  id: string;
  name: string;
  email: string;
}

// With type
type User = {
  id: string;
  name: string;
  email: string;
};

For this use case — describing the shape of an object — they are functionally equivalent. The compiled JavaScript output is identical. The editor behavior is the same. The error messages are nearly the same.

So why does the choice matter? Because they diverge in meaningful ways the moment your types get more complex.

What interface Can Do That type Cannot 🏗️

Declaration Merging

This is the most important feature exclusive to interface and the one that most developers either love or get burned by.

If you declare the same interface name twice in the same scope, TypeScript merges them automatically.

interface Window {
  userLocale: string;
}

interface Window {
  analyticsReady: boolean;
}

// TypeScript sees this as:
// interface Window {
//   userLocale: string;
//   analyticsReady: boolean;
// }

This is how you extend third party library types without modifying their source. If you have ever added custom properties to Express's Request object or extended global browser types, this is how it works.

// Extending Express Request in a .d.ts file
declare global {
  namespace Express {
    interface Request {
      currentUser?: User;
      requestId: string;
    }
  }
}

With type this is impossible. Declaring the same type name twice is a compile error.

📖 Declaration Merging — typescriptlang.org

Implements in Classes

Classes can implement interfaces directly, and the compiler enforces the contract cleanly.

interface Repository<T> {
  findById(id: string): Promise<T | null>;
  save(entity: T): Promise<T>;
  delete(id: string): Promise<void>;
}

class UserRepository implements Repository<User> {
  async findById(id: string) { /* ... */ }
  async save(user: User) { /* ... */ }
  async delete(id: string) { /* ... */ }
}

You can technically implement a type alias too, but only when it represents an object shape. The moment the type is a union, the compiler refuses.

type PrimaryKey = { key: number } | { key: string };

// Error — cannot implement a union type
class Entity implements PrimaryKey {
  key = 1;
}

📖 Interfaces — typescriptlang.org

What type Can Do That interface Cannot 🎯

This is where type genuinely pulls ahead. Everything listed here is impossible with interface.

Union Types

type Status = 'pending' | 'active' | 'suspended' | 'deleted';

type ApiResponse<T> =
  | { success: true; data: T }
  | { success: false; error: string };

Interfaces cannot express OR. Only AND. If you need to say "this is one of these things," you need type.

Discriminated Unions (The Pattern You Should Be Using More)

This is one of the most powerful patterns in TypeScript and it requires type.

type Shape =
  | { kind: 'circle'; radius: number }
  | { kind: 'rectangle'; width: number; height: number }
  | { kind: 'triangle'; base: number; height: number };

function getArea(shape: Shape): number {
  switch (shape.kind) {
    case 'circle':
      return Math.PI * shape.radius ** 2;
    case 'rectangle':
      return shape.width * shape.height;
    case 'triangle':
      return (shape.base * shape.height) / 2;
  }
}

The compiler knows exactly which properties are available in each branch. You cannot accidentally access shape.radius in the rectangle branch. This is making impossible states unrepresentable, and it is one of the best things TypeScript can do for you.

📖 Discriminated Unions — typescriptlang.org

Conditional Types

type IsArray<T> = T extends any[] ? true : false;

type Unwrap<T> = T extends Promise<infer U> ? U : T;

// Usage
type A = Unwrap<Promise<string>>; // string
type B = Unwrap<number>;          // number

This is the foundation of every utility type in TypeScript. Partial, Required, ReturnType, Awaited — all built with conditional types. None of it is possible with interface.

📖 Conditional Types — typescriptlang.org

Mapped Types

// Make all properties optional and readonly
type Snapshot<T> = {
  readonly [K in keyof T]?: T[K];
};

// Extract only string properties from an object type
type StringProperties<T> = {
  [K in keyof T as T[K] extends string ? K : never]: T[K];
};

type User = { id: number; name: string; email: string; age: number };
type UserStrings = StringProperties<User>;
// Result: { name: string; email: string }

📖 Mapped Types — typescriptlang.org

Template Literal Types

type EventName = 'click' | 'focus' | 'blur';
type Handler = `on${Capitalize<EventName>}`;
// Result: 'onClick' | 'onFocus' | 'onBlur'

type CSSProperty = 'margin' | 'padding';
type CSSDirection = 'Top' | 'Right' | 'Bottom' | 'Left';
type CSSLonghand = `${CSSProperty}${CSSDirection}`;
// 'marginTop' | 'marginRight' | ... | 'paddingLeft'

📖 Template Literal Types — typescriptlang.org

Tuple Types

type Pair<A, B> = [A, B];
type RGB = [number, number, number];
type HTTPMethod = ['GET' | 'POST' | 'PUT' | 'DELETE', string];

The Performance Question. Honestly Answered. ⚡

This comes up in every conversation and the answer is nuanced so I am going to give it the space it deserves.

Interfaces with extends are cached. Type intersections are not.

When TypeScript evaluates a type intersection (&), it recomputes the merged type every time it encounters it. When TypeScript evaluates an interface that extends another, it checks the named interface reference, which it has already cached.

// Recomputed on every use — not cached
type AdminUser = User & { permissions: string[] } & { department: string };

// Cached by name — more efficient for repeated use
interface AdminUser extends User {
  permissions: string[];
  department: string;
}

A real benchmark across 10,000 intersection types vs 10,000 extended interfaces showed the interface variant compiling in 1 minute 26 seconds versus 2 minutes 33 seconds for the intersection variant. That is almost half the compile time.

📖 TypeScript Performance Wiki — github.com/microsoft/TypeScript
📖 Benchmark — mykytam.com

But context matters

For most apps this difference will not show up in your daily work. Where it genuinely matters is in large monorepos with hundreds of deeply composed types, running full compilation in CI. If your CI builds are creeping up toward ten minutes, auditing your intersection types is a legitimate optimization worth doing.

For local development, the TypeScript language server evaluates types per file rather than the whole project, so the day to day impact is much smaller.

📖 LogRocket — Types vs Interfaces Performance

TypeScript 7 changes the picture

TypeScript 7 is a complete rewrite of the compiler in Go, targeting up to 10 times faster compile times across the board. Compile times should shrink from minutes to seconds, and language service operations like completions, renames, and refactorings become more responsive. When TypeScript 7 becomes the default, the performance gap between type and interface narrows significantly because the baseline is so much faster. The right choice for the compile time benefit today is interface extends over & intersections — but do not stress about it if you are on small to medium projects.

📖 Progress on TypeScript 7 — devblogs.microsoft.com
📖 TypeScript 7 Native Preview — developer.microsoft.com

The Declaration Merging Trap 🪤

This is the caveat that Matt Pocock at Total TypeScript correctly calls out as the main reason to be careful with interfaces as your default.

If you accidentally declare the same interface name twice in the same scope, TypeScript silently merges them. No error. No warning. Just a type that now has extra properties you did not intend.

// Somewhere in your codebase
interface User {
  id: string;
  name: string;
}

// Somewhere else — maybe a different file, maybe a library you imported
interface User {
  internalFlag: boolean; // silently merged in
}

// Now User requires internalFlag everywhere. Good luck debugging that.
const user: User = { id: '1', name: 'Jane' };
// Error: Property 'internalFlag' is missing

With type, the second declaration is an immediate compiler error. You find the problem at the point of declaration, not at the point of use.

📖 Total TypeScript — type vs interface

Tips and Tricks That Actually Matter in Production 🛠️

Use discriminated unions to make invalid states impossible

Stop using optional properties to represent different states of the same object. Model each state explicitly.

// The fragile way — optional properties everywhere
type Order = {
  status: 'pending' | 'shipped' | 'delivered';
  trackingNumber?: string; // only when shipped
  deliveredAt?: Date;      // only when delivered
};

// The correct way — each state is its own type
type Order =
  | { status: 'pending' }
  | { status: 'shipped'; trackingNumber: string }
  | { status: 'delivered'; trackingNumber: string; deliveredAt: Date };

// The compiler now enforces what belongs where
function handleOrder(order: Order) {
  if (order.status === 'shipped') {
    console.log(order.trackingNumber); // always defined here, no ?. needed
  }
}

📖 Narrowing — typescriptlang.org

Use `satisfies` to get both inference and validation

The satisfies operator (stable since TypeScript 4.9) lets you validate that a value matches a type while keeping the most specific inferred type.

type Palette = Record<string, string | [number, number, number]>;

// Without satisfies — TypeScript infers the wide type
const colors = {
  red: [255, 0, 0],
  green: '#00ff00',
} satisfies Palette;

// Now colors.red is inferred as [number, number, number], not string | [number, number, number]
// And colors.green is string, not string | [number, number, number]
colors.red.at(0); // works — TypeScript knows it's a tuple
colors.green.toUpperCase(); // works — TypeScript knows it's a string

Without satisfies you would have to choose between type safety and useful inference. Now you get both.

📖 satisfies operator — typescriptlang.org

Prefer `interface extends` over `&` for object composition

When you are combining object types, extends is more readable and more performant than &.

// Less readable, less performant in large codebases
type AdminUser = User & { permissions: string[] } & Timestamps;

// Better
interface AdminUser extends User, Timestamps {
  permissions: string[];
}

📖 TypeScript Performance — github.com/microsoft/TypeScript

Use `const` assertions for literal types

When you want TypeScript to infer the narrowest possible type from a value, as const is the move.

// Without as const — TypeScript infers string[]
const directions = ['north', 'south', 'east', 'west'];

// With as const — TypeScript infers readonly ['north', 'south', 'east', 'west']
const directions = ['north', 'south', 'east', 'west'] as const;
type Direction = typeof directions[number];
// Result: 'north' | 'south' | 'east' | 'west'

// Now adding an invalid direction is a compile error
function move(dir: Direction) { /* ... */ }
move('up'); // Error — not in the union

📖 const assertions — typescriptlang.org

Use template literal types to keep string patterns safe

If your codebase uses string patterns like route paths, event names, or CSS class names, template literal types let you enforce them at compile time.

type Route = `/api/${string}`;
type VersionedRoute = `/api/v${number}/${string}`;

function fetchData(route: Route) { /* ... */ }

fetchData('/api/users');         // fine
fetchData('/api/v2/products');   // fine
fetchData('/users');             // Error — does not start with /api/

📖 Template Literal Types — typescriptlang.org

Use `infer` for type level parsing

When you need to extract parts of a type programmatically, infer is the right tool.

// Extract the return type of any async function
type Awaited<T> = T extends Promise<infer R> ? R : T;

// Extract the element type of any array
type ElementType<T> = T extends (infer E)[] ? E : never;

// Extract parameter types of a function
type FirstParam<T> = T extends (first: infer F, ...rest: any[]) => any ? F : never;

type A = ElementType<string[]>; // string
type B = FirstParam<(name: string, age: number) => void>; // string

📖 Inferring within Conditional Types — typescriptlang.org

The Decision Framework 🗂️

Here is the clearest way I can give you to make the call.

Use interface when:

You are defining a contract that classes will implement
You are extending or augmenting third party library types
You are writing a library and want consumers to be able to extend your types via declaration merging
You are building deep object hierarchies and composition matters for compile performance

Use type when:

You need a union (|)
You need a conditional type
You need a mapped type or template literal type
You are defining tuples
You are defining function signatures (the syntax is cleaner)
You do not want accidental declaration merging to be possible
You are using functional patterns where each thing is its own distinct type

In practice: most experienced TypeScript teams land on one of two camps. Either "default to interface for objects, use type for everything else" or "default to type for everything, use interface only when declaration merging is needed." Both are defensible. The worst thing you can do is mix them randomly without a team decision.

Whatever you choose, write it down and enforce it with ESLint.

// .eslintrc — enforce your team's choice
{
  "rules": {
    "@typescript-eslint/consistent-type-definitions": ["error", "type"]
    // or: ["error", "interface"]
  }
}

📖 consistent-type-definitions — typescript-eslint.io

TypeScript 7 and What Is Coming 🔭

Two things worth knowing about the near future.

TypeScript 6.0 is the last release on the old JavaScript compiler codebase. It is being framed as a bridge release to prepare the ecosystem for TypeScript 7. TypeScript 6.0 will deprecate features to align with 7.0, and will be highly compatible in terms of type checking behavior.

TypeScript 7 features like --incremental, project reference support, and --build mode are all ported over and working in the native Go compiler. Most projects can now try the native preview with minimal changes.

What this means for the type vs interface question: the syntax is not changing. Your existing code works. The big shift is that the performance argument in favor of interface extends over & intersections becomes less urgent as the Go compiler makes everything faster. But correctness and clarity remain the right reasons to pick one over the other regardless of the compiler speed.

📖 TypeScript 6.0 Beta — devblogs.microsoft.com
📖 Progress on TypeScript 7 — devblogs.microsoft.com

The Short Version 👋

interface gives you declaration merging, clean class contracts, and slightly better compile performance for object composition through extends. Use it when you want extensibility to be explicit and intentional, or when you are writing library code that consumers will augment.

type gives you unions, conditional types, mapped types, template literals, tuples, and protection against accidental merging. Use it for everything that goes beyond describing a simple object shape.

For performance: prefer interface extends over type & intersections when composing many object types, especially in large codebases. The satisfies operator is your friend when you need both type safety and narrow inference. And discriminated unions are the pattern you should be reaching for every time you see optional properties that only make sense in certain states.

Pick a convention. Lint for it. Stop relitigating it every PR review.

Which camp are you in — team type or team interface? Drop it in the comments. I want to know if I will be starting a war.

🎭 I Switched to Playwright and I Am Not Going Back

Alvin Bellero — Sun, 08 Mar 2026 08:54:47 +0000

Let me paint you a picture.

It is 2019. You have a Selenium test suite that takes 45 minutes to run. Half the tests are flaky. There is a custom wrapper around WebDriver that one person wrote and only one person understands. That person left the company in 2020.

You are that person now.

Then Cypress came along and saved a lot of us. Fast, developer friendly, genuinely good developer experience. We migrated. We were happy. For a while.

Then you hit the wall. Cross browser testing? Painful. Multiple tabs? Good luck. Iframe handling? Let us not talk about it. File downloads? I have a story about that one but my therapist says I should stop bringing it up.

Enter Playwright. Built by Microsoft. Quietly battle tested by teams at serious scale. Currently sitting at v1.58 as of early 2026. And honestly? It fixed almost everything I had quietly accepted as just the way testing works.

This is not a beginner's guide. You already know what end to end testing is. You have opinions about async/await. You have been burned before. So let me just show you the parts that made me switch and genuinely never look back.

📌 All code examples are tested against v1.58.

Auto Waiting That Actually Works 🧘

Every action in Playwright, whether it is a click, a fill, or a check, automatically waits for the element to be attached to the DOM, visible on screen, stable and not mid animation, enabled, and not obscured by something else sitting on top of it.

All of that. Before it does anything. Without you asking.

// Goodbye forever:
// await page.waitForSelector('#submit-btn')
// await driver.wait(until.elementIsVisible(...))

// Hello:
await page.click('#submit-btn');

That one change alone eliminated roughly 30% of our flaky tests overnight. Not because those tests were badly written. Because half of our so called flakiness was just timing issues we had been papering over with sleep() calls like it was 2011. 🐒

📖 Auto Waiting — playwright.dev

True Cross Browser Support That Does Not Make You Want to Cry 🌐

Playwright ships with three browser engines built right in: Chromium, Firefox, and WebKit. These are not thin wrappers or third party drivers. They are first class, actively maintained engines.

And as of v1.57, Playwright moved from generic Chromium builds over to Chrome for Testing builds. Same test behavior, but now you are actually running on the same Chrome your users see. Headed mode uses chrome and headless mode uses chrome-headless-shell.

📖 Chrome for Testing in v1.57 — playwright.dev release notes

// playwright.config.ts
projects: [
  { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
  { name: 'webkit', use: { ...devices['Desktop Safari'] } },
  { name: 'mobile-chrome', use: { ...devices['Pixel 7'] } },
  { name: 'mobile-safari', use: { ...devices['iPhone 14'] } },
]

One command. Five browsers. Done. No Sauce Labs subscription needed for basic cross browser coverage. No separate CI pipeline per browser to babysit.

Cypress added Firefox support at some point. WebKit support there is still experimental. With Playwright, both were first class from the very beginning because the whole thing was designed that way from scratch.

📖 Cross Browser Testing — playwright.dev

Multiple Tabs and Windows Like a Normal Person 🗂️

OAuth flows. Payment redirects. Anything that pops open a new tab. All of it is handled natively in Playwright without needing workarounds or third party plugins.

// Just wait for the new tab and carry on
const [newPage] = await Promise.all([
  context.waitForEvent('page'),
  page.click('a[target="_blank"]')
]);

await newPage.waitForLoadState();
await expect(newPage).toHaveTitle(/Payment Confirmation/);

Browser contexts are where Playwright really pulls ahead though. Each context is a fully isolated browser session with its own cookies, its own local storage, and its own auth state. You can spin up multiple contexts inside a single test and simulate two different users interacting with the same page simultaneously.

// Two users. One test. Zero drama.
const userA = await browser.newContext();
const userB = await browser.newContext();

const pageA = await userA.newPage();
const pageB = await userB.newPage();

Try doing that cleanly in Selenium. I will be right here waiting. ⏳

📖 Browser Contexts — playwright.dev
📖 Pages and Tabs — playwright.dev

Network Interception That Does Not Feel Like a Hack 🔌

// Mock a specific API endpoint
await page.route('**/api/users', async route => {
  await route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify({ users: [{ id: 1, name: 'Test User' }] })
  });
});

// Silently kill analytics requests so they stop slowing down your tests
await page.route('**/*analytics*', route => route.abort());

// Fetch the real response, change one thing, send it back
await page.route('**/api/config', async route => {
  const response = await route.fetch();
  const json = await response.json();
  json.featureFlags.newDashboard = true;
  await route.fulfill({ response, json });
});

That third one is genuinely my favorite trick in Playwright. You get the real API response, flip one feature flag, and return it. You are testing the actual behavior of your app without mocking an entire endpoint. I reach for this all the time.

And as of v1.57, Playwright also reports and routes network requests from Service Workers through BrowserContext in Chromium. If you are building any kind of PWA, that is a big deal.

📖 Network Mocking — playwright.dev
📖 Service Worker Routing in v1.57 — playwright.dev release notes

The Clock API: Finally, Time Travel for Your Tests ⏰

This feature gets criminally undermentioned. page.clock gives you full control over time inside the browser: Date, setTimeout, setInterval, all of it.

// Freeze time at a specific moment
await page.clock.install({ time: new Date('2025-01-01T08:00:00') });
await page.goto('http://localhost:3000');

// Skip ahead two hours to trigger session expiry
await page.clock.fastForward('02:00:00');
await expect(page.getByText('Session expired')).toBeVisible();

// Or just park it at a specific time and assert
await page.clock.pauseAt(new Date('2025-01-01T10:00:00'));
await expect(page.getByTestId('current-time')).toHaveText('10:00 AM');

No more sneaking Date.now() mocks into your application code just to make a test pass. No more jest.useFakeTimers() gymnastics that only sort of work. Playwright reaches directly into the browser clock and takes over. Countdown timers, token expiry, scheduled notifications, time sensitive UI states — all testable without touching your production code.

📖 Clock API — playwright.dev

The Trace Viewer and the New Speedboard 🪄

When a test fails in CI with Selenium, you get a stack trace and maybe a screenshot if someone remembered to configure it. Playwright's trace viewer is a completely different experience. It is a full recording of your test: DOM snapshots at every action, every network request, every console log, screenshots throughout. You can scrub through it like rewinding a video.

// playwright.config.ts
use: {
  trace: 'retain-on-failure',
  screenshot: 'only-on-failure',
  video: 'retain-on-failure',
}

npx playwright show-trace trace.zip

Full interactive replay of your failed test, straight from a CI artifact, without ever needing to reproduce it locally. For any senior engineer who has wasted hours trying to reproduce a flaky test that only breaks on Tuesday in CI, this changes your life.

📖 Trace Viewer — playwright.dev

The newer addition I am equally excited about is the Speedboard, which landed in v1.57 and got improved in v1.58. It is a tab in the HTML reporter that lists all your tests sorted from slowest to fastest. At a glance you can see which tests are dragging the whole suite down and start asking useful questions about why.

📖 Speedboard in v1.57 — playwright.dev release notes

And with the Timeline view added in v1.58, when you are using merged reports across sharded runs, you get a full picture of what ran when across every machine. Sharding across ten workers and still having complete visibility? That is how a grown up CI setup looks.

The UI Mode and Trace Viewer also got quality of life updates in v1.58: native OS dark and light mode support, Cmd/Ctrl+F search inside code editors, and JSON responses that format themselves automatically. Small things. The kind of small things that make you feel like the team actually uses their own tool every day.

📖 Timeline and UI Mode updates in v1.58 — playwright.dev release notes

Playwright Agents: AI That Writes and Heals Your Tests 🤖

This is the newest addition and honestly the most interesting direction the project is heading. Starting in v1.56, Playwright ships with three official AI agent definitions: planner explores your app and produces a structured Markdown test plan, generator takes that plan and turns it into actual Playwright test files, and healer runs your suite and automatically fixes tests that broke because a selector changed.

npx playwright init-agents --loop=claude
# or if you prefer
npx playwright init-agents --loop=vscode

The healer is where I spend most of my attention. Any sufficiently large test suite has tests that break not because the feature broke but because someone renamed a button or restructured a component. Instead of manually hunting down 40 selectors after a big UI refactor, the healer finds what broke and repairs the locators.

Is it production perfect yet? Not entirely. But it ships as a first class part of Playwright itself, not some community plugin that might go unmaintained in six months. The trajectory here is very clear.

📖 Playwright Test Agents in v1.56 — playwright.dev release notes
📖 Playwright Agents Guide — playwright.dev

Codegen Now Writes Assertions For You 🧠

The test generator got a nice upgrade in v1.58. When you use npx playwright codegen to record your interactions, it now automatically generates toBeVisible() assertions alongside the actions. Before this, Codegen was great for capturing clicks and fills but you still had to go back and add assertions yourself. Now it scaffolds them as you go, and you can toggle the behavior off in the Codegen settings UI if you prefer the old way.

// What Codegen produces now after you submit a form:
await page.getByRole('button', { name: 'Submit' }).click();
await expect(page.getByText('Success! Form submitted.')).toBeVisible(); // generated for you ✨

Less manual work. Faster test writing. Good change.

📖 Codegen — playwright.dev
📖 Auto assertions in Codegen, v1.58 — playwright.dev release notes

webServer Finally Knows When Your App Is Actually Ready 🚦

This one sounds small but it has saved me multiple CI headaches. In v1.57, the webServer config got a wait field that accepts a regex. Playwright now holds off on running tests until your dev server logs something that matches.

// playwright.config.ts
export default defineConfig({
  webServer: {
    command: 'npm run start',
    wait: {
      stdout: /Listening on port (?<my_server_port>\d+)/
    },
  },
});

Use a named capture group and Playwright automatically passes it through as an environment variable, so you can pick up the dynamic port in your test config.

test.use({ baseURL: `http://localhost:${process.env.MY_SERVER_PORT ?? 3000}` });

No more hardcoded ports. No more waitForTimeout(5000) at the top of every file because someone got burned by a slow CI machine once and quietly added it three years ago and nobody knows why it is still there.

📖 webServer wait field in v1.57 — playwright.dev release notes
📖 webServer config — playwright.dev

TypeScript Just Works 🟦

Zero configuration. No plugins to install. No @types/ packages to track down. You write TypeScript and Playwright is fine with it.

import { test, expect, Page } from '@playwright/test';

async function loginAs(page: Page, email: string, password: string) {
  await page.goto('/login');
  await page.fill('[name="email"]', email);
  await page.fill('[name="password"]', password);
  await page.click('[type="submit"]');
  await expect(page).toHaveURL('/dashboard');
}

test('admin can access settings', async ({ page }) => {
  await loginAs(page, 'admin@example.com', 'secret');
  await page.click('nav >> text=Settings');
  await expect(page.locator('h1')).toHaveText('Settings');
});

Full type inference on the page object. Autocomplete on locators. Typed fixture overrides. It just feels good to work in.

📖 TypeScript in Playwright — playwright.dev

The One Thing I Still Miss From Cypress

The time travel debugging in the Cypress test runner. That interactive, step through experience when you are writing a new test locally is still the most comfortable way to author tests I have ever used. Playwright's UI mode is genuinely closing the gap but Cypress still wins on raw first time test writing comfort.

That is the only thing on my list. Just the one. Think about what that means.

📖 Playwright UI Mode — playwright.dev

Should You Actually Switch?

If you are on Selenium, yes. Please. There is no honest argument for Selenium on a modern web app in 2026 unless you have legacy constraints you genuinely cannot escape yet.

If you are on Cypress, it depends. If you keep running into the walls I described, cross browser, multi tab flows, PWA testing, the Clock API, then yes the migration is worth it. If Cypress is genuinely working well for your team and productivity is good, the switching cost might not make sense today. But watch this space. The gap between the two tools is growing with every Playwright release.

If you are starting from scratch, Playwright is the default answer. Not because Cypress is bad but because Playwright was designed to handle everything from the beginning.

📖 Cypress to Playwright migration: A step-by-step guide — playwright.dev

The Short Version 👋

Playwright v1.58 gives you auto waiting that actually eliminates flakiness (docs), real cross browser support running on Chrome for Testing builds (v1.57 notes), native multi tab and multi user testing (docs), clean network interception including Service Worker routing (docs), a Clock API that controls browser time directly (docs), a Trace Viewer and Speedboard that make debugging CI failures actually manageable (docs), AI agents that write and repair your tests (v1.56 notes), smarter Codegen with automatic assertions (v1.58 notes), and TypeScript support with zero setup (docs).

It is what end to end testing should have been all along. And the team is still shipping.

Go write some tests. Good ones this time. 🎭

Already on Playwright? Drop your favorite underrated feature in the comments. I am always looking for the next trick I did not know existed.

🌟 Extensions Dump: UnitFlux and CodeMorph!

Alvin Bellero — Sun, 10 Nov 2024 09:51:38 +0000

Hey there, developers! 👋

I'm excited to share two new VSCode extensions that I recently published: UnitFlux and CodeMorph! These tools aim to streamline your workflow and make your life a little easier in the editor.

Let’s dive into what they’re all about! 🚤

🎨 UnitFlux: Effortless Unit Conversion for Responsive CSS

CSS design can be tricky, especially when trying to achieve fluid layouts.

That’s where UnitFlux comes in! With this extension, you can seamlessly convert pixels (PX) to other responsive units like em and rem directly in your editor. 🎯

Why Use UnitFlux?

📏 Boosts Responsive Design – Instantly scale pixel-based values to flexible units for a design that adjusts to any screen size.
⚡ Save Time – Forget the manual calculations; UnitFlux does the work for you!
🖌️ Enhanced CSS Workflow – Perfect for designers and developers aiming for fluid, responsive layouts without the hassle.

🔄 CodeMorph: Unicode Compatibility Made Easy

Ever had issues with non-ASCII characters in JSON files? 🐛

That’s where CodeMorph steps in. This extension allows you to quickly convert any non-ASCII characters in JSON files to Unicode escape sequences, ensuring compatibility across various environments and systems. ✅

Why Use CodeMorph?

🌍 Ensures JSON Compatibility – Unicode-escape all non-ASCII characters to avoid encoding issues in JSON.
💻 Effortless Transformation – Convert characters with a click and make your JSON files universally readable.
✨ Handy Commands – Easy-to-trigger command from the Command Palette and Context Menu (File Explorer).

👉 With CodeMorph, say goodbye to encoding headaches and ensure your JSON files are ready for any system!

🚀 Ready to Try Them Out?

Both UnitFlux and CodeMorph are available now on the VSCode Marketplace! 🎉

Check them out, give them a spin, and let me know what you think. I’d love your feedback as I continue to improve these tools and add new features!

📸 Cover Photo by Pankaj Patel on Unsplash

💼 Marking One Year in Singapore: My Life as an Expat Software Engineer

Alvin Bellero — Tue, 04 Jul 2023 16:56:48 +0000

From Home to A New Horizon

Just over a year ago, I packed my bags 🧳 and embarked on an adventure, trading the comfort of my home country, the Philippines 🇵🇭 for the vibrant city of Singapore 🇸🇬.

I took on an exciting role at the global tech giant, Equinix, as a Software Engineer 👨‍💻. Now, I'm looking back and celebrating 🎉 the milestone of my first work-anniversary in this exhilarating role!

Building Resilience

Navigating life 🧭 in an unfamiliar country as an expat, especially for the first time, has indeed been challenging.

Living alone, away from my family, has at times been a lonely 😔 experience. Searching for a place 🏠 to call home in a city foreign to me was one of the first obstacles I faced. I sifted through numerous listings 🗂️, contacted lots of strangers and visited countless properties 🏢 before finally finding a place I could settle into 🛋️.

Yet, amidst these challenges, I found resilience and perseverance. Every hurdle faced was a step closer to making Singapore feel like home. I was fuelled by my passion, the drive to broaden my horizons, and above all, the thought of providing a better life for my family ❤️.

Embracing Cultural Diversity

Living in Singapore as an expat has also been an enriching journey. Apart from honing my professional skills, I've been immersed in a melting pot of diverse cultures, languages, and traditions 🎏.

One of the highlights is discovering the love for Indian food 🥘. My taste buds have embarked on an adventure of their own, exploring the symphony of spices and flavours in dishes like mutton curry, butter chicken, biryani, naan and many more! 🍗 🫓 🤤.

I fondly recall a friend, jokingly suggesting that I must have been Indian in my past life! 🤣 ❤️

Moreover, I've also developed a special fondness for local delights such as Laksa, a spicy noodle soup 🍜, Hainanese Chicken Rice, Singapore's national dish 🍛 and my Perfect Pair, a cup of Kopi ☕ and Kaya Toast 🥪.

These culinary journeys have not only tantalized my palate but also provided a comfort away from home 😌.

A Year of Extraordinary Experiences

My journey 🗺️ in the past year has been nothing short of extraordinary. I've had the privilege to work and contribute alongside some of the best people here in Singapore and Silicon Valley 👩‍💻👨‍💻, an experience that has enriched my professional life immensely.

Participating in an internal (global) Hackathon was a standout moment, where our team secured the People's Choice Award 🏆 (out of 41 teams participated), a testament to our combined efforts and ingenuity.

I've met also an array of cool people, including fellow Filipinos 🇵🇭, creating a sense of community in this foreign land.

I've attended countless tech meetups and events 🎟️, each one a learning opportunity and a chance to network with like-minded individuals.

Giving Back to the Tech Community

In addition to my work at Equinix, I've expanded my contributions to the open-source community 👨‍💻. I've had the opportunity to create tools and solutions that can help fellow developers—which has been incredibly rewarding 🎁.

I regularly update my GitHub Profile with all of my latest works! 🌟

This year, I also began my own blog 📝 (yes, this blog!). It's always been a fun way to share my ideas and connect with other tech enthusiasts.

Reflections and Future

Celebrating one year as an Expat Software Engineer isn't just a work-anniversary, it's a nod to my journey of growth and a promise of the exciting adventures that lie ahead.

Here's to a fantastic year, the lessons learned 🎓, the friendships made, and the thrilling journey that awaits! 🚀

Cover Photo by Nils Nedel on Unsplash

📦 Stay Organized and Efficient with Auto-Label-Pulls Github Action

Alvin Bellero — Sat, 01 Jul 2023 03:34:12 +0000

❓ What is `auto-label-pulls`?

Auto Label Pulls is a robust GitHub Action that can significantly streamline the process of labeling Pull Requests. Its branch-based mechanism offers the flexibility to cater to various project needs, making it an indispensable tool for any GitHub project maintainer.

Whether you have a small project or manage a large repository with tons of pull requests, auto-label-pulls can help you stay organized and save valuable time.

💡 Key Features

Easy to Set Up: Getting started with auto-label-pulls is a breeze. All you need to do is include the action in your GitHub workflow file and configure the necessary parameters.
Automatic Label Assignment: Labels are automatically assigned to new pull requests based on the target branch, removing the need for manual labelling.
Customizable: You can configure which labels correspond to which branches, allowing you to use in a way that suits your project's needs.

🚀 Getting Started

Using auto-label-pulls is simple and straightforward:

First, add the action to your GitHub workflow file (.github/workflows/main.yml).

name: Workflow Name

on:
  pull_request:
    types: [opened]

jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      - name: Assign labels
        uses: shiftEscape/auto-label-pulls@v1.0.0
        with:
          token: "${{ secrets.GITHUB_TOKEN }}"
          config-path: ".github/config/auto-label-pulls.json"

NOTE: Use this action only for pull_request event of type opened.

Second, create a configuration file (.github/config/auto-label-pulls.json) for the mapping of labels to branches.

{
  "master": "🚀 Production Deployment",
  "develop": "🧪 SIT Deployment"
}

In the above example, when a Pull Request is made to master branch, "🚀 Production Deployment" label will be assigned to that PR and so on and so forth.

💡 Visit the Action's Dashboard for more info: https://github.com/marketplace/actions/auto-label-pulls

👏 And there you have it, folks!

By incorporating auto-label-pulls into your GitHub workflow, you're not just organizing your process – you're revolutionizing it.

Explore the tool, share your thoughts, and let's transform the open-source space together!

Thanks for reading! 😉

🤖 ChatGPT meets Firestore: Create Intelligent Conversations in Your App

Alvin Bellero — Fri, 30 Jun 2023 15:51:52 +0000

👋 🤝 Hello, everyone! It's been a long time!

⚡️ Quick Story

I can still vividly recall the excitement I felt when Firebase announced Extensions at the 2019 Summit in Madrid, Spain. I immediately saw the immense value they could bring to us developers, especially for those of us heavily relying on Firebase products.

Now, as AI's popularity soars, I've seen a multitude of innovative applications powered by this technology, giving rise to increasingly beneficial products. Truly, the sky's the limit when it comes to AI's potential!

👀 What's New?

It's been a week now since the Firebase Team approved my first-ever Firebase Extension: Chatbot with ChatGPT ! 🥳 👏 🍾

It is an extension that integrates the ChatGPT Model from OpenAI and designed to facilitate AI-based conversations in real-time chat applications backed by Firestore.

By making use of Firebase and ChatGPT's powerful language processing capabilities, this extension empowers developers to implement AI-based automated interactions within their apps, making them more engaging and interactive!

📌 How to Use

Setting up and using Chatbot with ChatGPT is easy.

Go to the extensions page and click Install in Firebase console button. Follow the prompts, and you're good to go!

⚙️ Configurable Parameters

Collection Path: Path to a Cloud Firestore collection which will represent a discussion with OpenAI's ChatGPT.
Prompt Field: The field in the message document that contains the prompt. (Default: prompt)
Response Field: The field in the message document into which to put the response. (Default: response)
Cloud Functions Location: Where do you want to deploy the functions created for this extension? For help selecting a location, refer to the location selection guide.
Language Model: Which language model do you want to use? Refer to OpenAI's Model Reference.
Temperature: What sampling temperature to use, between 0 and 2. Higher values like 0.8 will make the output more random, while lower values like 0.2 will make it more focused and deterministic. Learn more here.
Nucleus Sampling Probability: An alternative to sampling with temperature, called nucleus sampling, where the model considers the results of the tokens with top_p probability mass. So 0.1 means only the tokens comprising the top 10% probability mass are considered. Learn more here.

🎬 Demo

For this demo, here's my configured params:

OpenAI API Key: *******************
Collection path: users/{uid}/messages
Prompt field: (default - prompt)
Response field: (default - response)
Language Model: GPT-3.5

That's all folks! 🤜🤛

Give it a try, please share your experiences, thoughts, and suggestions. Also, please don't forget to share this to your friends! 😊

Thank you so much! 🙇

🚀 Firebase Hosting: Free Hosting for your First Web Project

Alvin Bellero — Sun, 14 May 2023 07:49:45 +0000

Are you looking for a hosting solution for your first Web project? Look no further than Firebase Hosting! Firebase Hosting is a cloud-based hosting service provided by Google's Firebase platform, and it's completely free to use.

What makes Firebase Hosting stand out is its powerful features and easy setup process. You can quickly deploy static web pages, single-page applications, and even dynamic server-side content. Plus, Firebase Hosting comes with automatic SSL, a global content delivery network, and easy integration with other Firebase services.

So if you're a developer looking to launch your first web project, give Firebase Hosting a try. It's a powerful, flexible, and affordable hosting solution that can help you get up and running in no time!

💡 To learn more about Firebase Pricing, please check this out.

🏗️ Setting up Firebase Hosting

Setting up Firebase Hosting for your web project is a straightforward process. Follow these steps to get started:

Create a Firebase account
If you don't already have a Firebase account, go to the Firebase Website and sign up for a free account. Once you're logged in, you'll see the Console, which is where you'll manage your Firebase projects.
Create a Firebase project
In the Firebase console, click on the "Create a project" button to create a new Firebase project. Follow the prompts to name your project and enable Google Analytics if you want to track user behaviour on your website (optional).
Install the Firebase CLI
The Firebase CLI (Command Line Interface) is a tool that you'll use to deploy your website to Firebase Hosting. To install the Firebase CLI (globally), open a terminal window and run the following command:
```
npm install -g firebase-tools
```
Initialize your Firebase project
Once you have the Firebase CLI installed, navigate to your project directory in your terminal and run the following command:
```
firebase init hosting
```

💡 This will prompt you to the Firebase Hosting option. Follow the prompts to set up your project for hosting.

🚀 Deploying your website to Firebase Hosting

With your project set up for hosting, you're now ready to deploy your website to Firebase Hosting. Follow these steps to deploy your website:

Build your website
Before you can deploy your website, you'll need to build it. This typically involves running a build command that compiles your source code into a production-ready format. The specific build command will depend on your project's build system. Once your website is built, you should have a directory containing your compiled files.
Deploy your website
In your terminal window, navigate to the directory containing your compiled files and run the following command:
```
firebase deploy
```

💡 This will deploy your website to Firebase Hosting, and you'll be given a URL where you can access your website.

Congratulations! 🤝

You've now set up Firebase Hosting for your web project and deployed your website. With its powerful features and easy deployment process, you'll be able to manage your website hosting needs with ease.

😎💯👌

P.S. Catch up on the highlights from Firebase @ Google I/O ‘23! 🤯 ❤️

🧑‍💻 Visual Studio Code Productivity Hacks: My Favourite 15 Extensions

Alvin Bellero — Sat, 25 Feb 2023 18:34:17 +0000

Do you use Visual Studio Code (VSCode) for your coding projects? If so, you know how important it is to have the right tools at your disposal.

Luckily, there are a ton of extensions available that can help you streamline your workflow and boost your productivity.

In this article, I'm going to share my top 15 favourite VSCode extensions that have become essential productivity hacks in my daily work.

Whether you're a seasoned developer or just getting started with VSCode, these extensions are sure to help you get more done in less time.

So, without further ado, let's dive in!

💁 — John a.k.a "EverReady", Software Engineer, 25

1. Auto Rename Tag

⭐️ Jun Han

💁 Automatically rename paired HTML/XML tag.

💡 This extension will save you time finding the other end of the existing tag during an update! Please do read their docs especially the Note section.

2. Better Comments

⭐️ Aaron Bond

💁 Improve your code commenting by annotating with alert, informational, TODOs, and more!

💡 Commenting is an essential part of programming that helps to improve code quality, readability, and maintainability. By taking the time to write clear and concise comments, you can make your code more accessible and easier to work with for yourself and other developers!

3. CodeMap

⭐️ Oleg Shilo

💁 Interactive code map for quick visualization and navigation within code DOM objects (e.g. classes, members).

💡 I personally use this one to map custom patterns that I want including logging (debuggers | logs) & comments!

4. Code Runner

⭐️ Jun Han

💁 Run code snippet or code file for multiple languages

5. Color Picker

⭐️ anseki

💁 Helper with GUI to generate color codes such as CSS color notations.

💡 You can actually change your colors IN PLACE by using the Color Picker. How cool is that? 🤯

6. Console Buddy

⭐️ Yours Truly

💁 (Shameless Plug) A Snippet Extension that provides a collection of Web Console API snippets that allows you to quickly generated logging preference!

7. ESLint

⭐️ Microsoft

💁 Integrates ESLint JavaScript into VS Code.

💡 Thanks, Microsoft! 🙇🏻‍♂️

8. GitLens — Git supercharged

⭐️ GitKraken

💁 Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more

💡 In case you wanna find out who wrote a crappy, garbage line of code(s).... But then it shows: "You · 3 months ago" 👀

9. Import Cost

⭐️ Wix

💁 Display import/require package size in the editor

💡 Gives you more insights to all the packages you're installing. Something to think about.. 🤔💭

10. Inline fold

⭐️ Mohammed Alamri

💁 A custom decorator that "fold" matching content in single line

💡 The Tailwind CSS Framework is really great but it results in a lot of verbose classes. For that particular problem, this extension comes in handy.

11. Live Server

⭐️ Ritwick Dey

💁 Launch a development local Server with live reload feature for static & dynamic pages

💡 This spins up a NodeJS server and serves your HTML file with all the assets from the given directory. On top of that, all of your changes will be reflected immediately upon saving! Pretty cool, huh? 😎

12. indent-rainbow

⭐️ oderwat

💁 A simple extension to make indentation more readable.

💡 Love the RGB colours that matches with your fancy keyboard lighting? Check this out! 🌈

13. Prettier - Code formatter

⭐️ Prettier

💁 Enforces a consistent style by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary.

💡 Speechless...

14. SonarLint

⭐️ SonarSource

💁 Like a spell checker, SonarLint highlights Bugs and Security Vulnerabilities as you write code, with clear remediation guidance so you can fix them before the code is even committed

💡 We always learn from our misteaks 🙃🥩

15. Thunder Client

⭐️ Ranga Vadhineni

💁 Lightweight Rest API Client for VS Code

That's all folks! 🤜🤛

Are there any other extensions that you use? If so, be sure to let me know in the comments! 😉💯

🌎 Publishing Your Extensions to Visual Studio Marketplace

Alvin Bellero — Sun, 19 Feb 2023 01:55:50 +0000

In today's world, technology is evolving at a fast pace, and developers are constantly looking for ways to improve their productivity and streamline their workflow. One of the tools that has gained immense popularity in recent years is Visual Studio Code (VSCode). With its robust set of features and extensive library of extensions, VSCode has become the go-to code editor for many developers.

💡 But did you know that you can also create your own extensions for VSCode and share it with the community? If you missed my last post about "Creating Your First VSCode Extension Theme", you can check that out here.

In this article, we will explore the process of publishing your own extensions to the VSCode Marketplace. Whether you're looking to solve a specific problem, add new features, or just share your work with others, publishing extensions to the marketplace is an excellent way to contribute to the developer community and improve your own development experience. 🙌 😉

✨ Setup You Microsoft Azure DevOps Account

As you've probably know, VSCode is created and maintained by Microsoft. With that, we now have a single login for Azure Cloud Services and VSCode Extensions.

Head on to https://dev.azure.com/ website and create an account. You can opt to sign in with your Github account or just register with your personal email.

Once you've successfully registered, you will be redirected to your Azure DevOps Dashboard page under your created Organization name.

🪙 Create your Personal Access Token (PAT)

This will be used as your authentication in publishing your extensions in the marketplace.

Click on the User Profile settings icon beside your avatar and choose Personal access tokens.

Click New Token to create your Token.
Add your Token Name
Under Organization, select All accessible organizations
For Expiration, select Custom defined which will default to 1 year from now as the maximum expiration time
Under Scopes, make sure Custom defined is selected.
At the bottom, click Show all scopes and scroll down to Marketplace section
Select the Manage option
And lastly, click the blue Create button

🚨 WARNING: Make sure you SAVE A COPY of your newly created access token (PAT) as Azure will not store it and you will not be able to see it again. And most importantly, don't share it to anyone! 👀 🔐

📝 Create a Publisher

This will be your Publisher Name attached to your extension when it is available to the marketplace.

Navigate to: https://marketplace.visualstudio.com/manage and you should see a Create Publisher page. The only required fields here are the Name and ID of the publisher. The rest is optional.

If all goes well, you will be redirected to Manage Publishers & Extensions page. Keep that page open as we will be returning to it later.

📦 Prepare Your Extension

Here are some steps to ensure your extension's smooth transition to marketplace.

Open your extension's folder in VSCode and go to your package.json file and make sure these properties are being set.

{
  "publisher": "<Your Publisher ID>",
  "repository": {
    "type": "git",
    "url": "<Your repository URL>"
  },
  "keywords": ["<Keyword 1>", "<Keyword 2>"]
}

💡 NOTE: Make sure your LICENSE file is existing on your ROOT repository as VSCode will check this during packaging / publishing.

🚀 Package and Publish it!

Once your extension is ready to go, you can package and publish it by using the terminal only.

Open the integrated terminal in VSCode and install their extension plugin by running:

npm install -g vsce

vsce login <You Publisher ID>

🔐 You will then be prompted to input your Personal Access Token (PAT). Copy and paste it there and tap Enter key.

Next, you can build a package of your theme by running:

vsce package

💡 The plugin will automatically create a .vsix file in your extension's root directory indicating the package version on the filename. Make sure also NOT to check in this file to your repository.

To publish it to marketplace, run:

vsce publish

To verify the status of your deployment, navigate to your Manage Publishers & Extensions page and there you can see your extension's in "Verifying" status.

💡 This may take a while and as soon as this process is complete, you can now see your extension's version and a green check mark before it!

🚧 Updating your Extension

For version updates, make sure you have a clean GIT working directory before publishing a PATCH, MINOR and MAJOR update.

vsce publish <patch|minor|major>

The plugin will automatically handle the semantic versioning so you won't have to manually do it by yourself.

💡 TIP: Run vsce package every time you publish a new update 😉

🎉 Congratulations!

And there you have it! Your extension is now available to the community for installation! Share it to your social media and friends! ❤️

🎨 Creating Your First VSCode Extension Theme

Alvin Bellero — Wed, 15 Feb 2023 14:05:31 +0000

Visual Studio Code (VSCode) is a popular open-source code editor developed by Microsoft. With its flexible and extensible architecture, developers can customise and enhance their editing experience by creating their own extensions.

Recently, I decided to publish my own, preferred theme to Visual Studio Marketplace, ThemeNemo.

If you're looking for other themes, please check this out! 💯 🤜🤛

In this article, I will guide you through the process of creating your first theme (based on my own experience).

Whether you're a seasoned developer or just getting started, this will help you get up and running.

⚡ Set up your Development Environment

To start creating your VSCode extension, you'll need to set up a development environment on your machine. This typically involves installing Visual Studio Code and Node.js.

For VSCode Installation, refer here.
For Node and NPM installation, you can check this article.

✨ Create a New Extension Project

Once your development environment is set up, you can create a new extension project using the VSCode Extension Development Kit (VSCode-EDK) or the Yeoman generator for VSCode extensions.

npm install -g yo generator-code

🏃 Run "`Yo Code`"

The Yeoman Generator will walk you through the steps required to create your customisation or extension prompting for the required information.

To launch the generator simply type:

yo code

The CLI will walk you through the generation process and asks you about your extension's preference. Please refer to the actual generation below.

AND ... VOILA! 🎉

You have now successfully generated your theme files! Open it in VSCode and here's the file list looks like.

AWESOME! ... But wait! There's more! 👀

🔧 Debug Your Extension

You may be wondering how the default theme looks like. To view it, go to your Menu → Run and choose Start Debugging (F5).

This will open a new instance of VSCode Editor and provides you your debugger tools from your main editor.

This is the bare, default theme of VSCode 😕

🎨 Customise Your Theme

Start changing the colour values inside the JSON file. It will automatically be reflected to the Debugging Window after you save it.

Isn't it nice? 🤯

💥 Bonus Tip!

During the process of my theme creation, it is really hard for me tell which part of VSCode is changing whenever I update a particular set of colours from the JSON file.

So I searched the internet and found this gem! 💎

https://themes.vscode.one/

With Theme Studio, you can easily customise your own theme using their visual tools, change it the way you like and even get inspiration from existing themes in the community by forking their themes! 💯

🚀 Publish Your Theme Extension

Finally, once your extension is complete and tested, you can publish it to the VSCode Marketplace so that others can use it.

This involves creating a publisher account, packaging your extension, and submitting it for review by the VSCode Team.

⚡ UPDATE: I created a separate post for that here if you want to know more.

Just follow the steps and see your theme in the marketplace in all of its glory!

That's all folks! You can also share your experience in the comments section below.

P.S. Don't forget about your theme logo! 😆

DEV Community: Alvin Bellero

📦 I Built 3 Astro Integrations and Shipped Them to npm — Here's What They Do

🎯 What's an Astro Integration, anyway?

📦 @shiftescape/astro-bundle-budget

🔍 @shiftescape/astro-env-inspector

🗺️ @shiftescape/astro-toolbar-routes

Using all three together

What I Learned Building These

What's Next

🌟 Extensions Dump: Key Tracer!

🔍 Key Tracer: Never Lose Your Place in a JSON File Again

✨ What It Does

🚀 Features

📦 Installation

⚙️ Configuring the Delimiter

💡 When Does This Actually Help?

🚀 Give It a Try

🧠 TypeScript: Type vs Interface — Stop Guessing, Start Knowing

First, What Do They Actually Do?

What interface Can Do That type Cannot 🏗️

Declaration Merging

Implements in Classes

What type Can Do That interface Cannot 🎯

Union Types

Discriminated Unions (The Pattern You Should Be Using More)

Conditional Types

Mapped Types

Template Literal Types

Tuple Types

The Performance Question. Honestly Answered. ⚡

Interfaces with extends are cached. Type intersections are not.

But context matters

TypeScript 7 changes the picture

The Declaration Merging Trap 🪤

Tips and Tricks That Actually Matter in Production 🛠️

Use discriminated unions to make invalid states impossible

Use satisfies to get both inference and validation

Prefer interface extends over & for object composition

Use const assertions for literal types

Use template literal types to keep string patterns safe

Use infer for type level parsing

The Decision Framework 🗂️

TypeScript 7 and What Is Coming 🔭

The Short Version 👋

🎭 I Switched to Playwright and I Am Not Going Back

Auto Waiting That Actually Works 🧘

True Cross Browser Support That Does Not Make You Want to Cry 🌐

Multiple Tabs and Windows Like a Normal Person 🗂️

Network Interception That Does Not Feel Like a Hack 🔌

The Clock API: Finally, Time Travel for Your Tests ⏰

The Trace Viewer and the New Speedboard 🪄

Playwright Agents: AI That Writes and Heals Your Tests 🤖

Codegen Now Writes Assertions For You 🧠

webServer Finally Knows When Your App Is Actually Ready 🚦

TypeScript Just Works 🟦

The One Thing I Still Miss From Cypress

Should You Actually Switch?

The Short Version 👋

🌟 Extensions Dump: UnitFlux and CodeMorph!

🎨 UnitFlux: Effortless Unit Conversion for Responsive CSS

Why Use UnitFlux?

🔄 CodeMorph: Unicode Compatibility Made Easy

Why Use CodeMorph?

🚀 Ready to Try Them Out?

💼 Marking One Year in Singapore: My Life as an Expat Software Engineer

From Home to A New Horizon

Building Resilience

Embracing Cultural Diversity

A Year of Extraordinary Experiences

Giving Back to the Tech Community

Reflections and Future

📦 Stay Organized and Efficient with Auto-Label-Pulls Github Action

❓ What is auto-label-pulls?

💡 Key Features

🚀 Getting Started

👏 And there you have it, folks!

🤖 ChatGPT meets Firestore: Create Intelligent Conversations in Your App

👋 🤝 Hello, everyone! It's been a long time!

⚡️ Quick Story

👀 What's New?

📦 `@shiftescape/astro-bundle-budget`

🔍 `@shiftescape/astro-env-inspector`

🗺️ `@shiftescape/astro-toolbar-routes`

Use `satisfies` to get both inference and validation

Prefer `interface extends` over `&` for object composition

Use `const` assertions for literal types

Use `infer` for type level parsing

❓ What is `auto-label-pulls`?

🏃 Run "`Yo Code`"