DEV Community: Amir Shekari

Beta and Production Builds in Expo - Fully Local, No EAS Required

Amir Shekari — Sun, 05 Jul 2026 11:32:17 +0000

Ever installed a beta build on your phone, and it silently replaced your production app? Then you opened it, and it was logged into your production account, talking to your production API? Me too. That's the day I decided my beta and production builds needed to be two completely separate apps.

The usual answer is "just use EAS build profiles." And EAS is fine, but you don't need it for this. Everything EAS does with build variants is powered by something that already lives in your project: Continuous Native Generation. The android and ios folders in an Expo project are generated output, the same way a build folder is. Your app config is the source of truth, and npx expo prebuild regenerates the native projects from it. That means we can generate a different native project per environment, on our own machine, with nothing but the Expo CLI.

Let's build that setup step by step. I'm using Expo SDK 57 here, but nothing in this post is SDK-specific — the same approach works at least back to SDK 50. The app is called MyApp; swap in your own name. Everything below is a real, working project you can clone and run: vanenshi/expo-build-variants.

Step 1: delete your native folders (mentally, at least)

If you have android/ and ios/ checked into git and you've been editing them by hand, this approach won't work, because prebuild will overwrite your edits. So the first decision is: the app config owns the native projects.

# .gitignore
/android
/ios

New projects created with create-expo-app already do this — the Expo docs state that the android and ios directories are added to .gitignore automatically. If yours is an older project, add the two lines yourself, and move any manual native edits into config plugins first.

Why does this matter for environments? Because once the native projects are generated, we can generate them differently per environment. One command gives you a beta app, another gives you the production app, and they never share a single native file.

Step 2: make the config dynamic

Rename app.json to app.config.ts (Expo picks up dynamic config automatically) and drive it with a single variable:

// app.config.ts
import { ExpoConfig } from "expo/config";

// default to beta: the safe variant is the one you get by accident
const APP_VARIANT = process.env.APP_VARIANT ?? "beta";
const IS_BETA = APP_VARIANT === "beta";

const config: ExpoConfig = {
  name: "MyApp",
  slug: "myapp",
  version: "1.0.0",
  ios: {
    bundleIdentifier: IS_BETA ? "com.example.myapp.beta" : "com.example.myapp",
  },
  android: {
    package: IS_BETA ? "com.example.myapp.beta" : "com.example.myapp",
  },
};

export default config;

That's the whole trick. APP_VARIANT=prod npx expo prebuild gives you the production native project; run it without the variable and you get beta. Defaulting to beta is deliberate — if anyone (you, a script, CI) forgets the variable, the accident produces a harmless beta build, never a production one. This is, incidentally, exactly the mechanism Expo's own multiple app variants tutorial uses — they just set APP_VARIANT from eas.json profiles instead of your shell.

Note that APP_VARIANT only exists at prebuild time, on your machine. It never ships in the app, and the app never reads it. That's deliberate, and step 5 shows what the app reads instead.

Step 3: why a separate namespace, not just an env variable

You might be tempted to keep one bundle identifier and switch the API URL with an env variable. Please don't. Let's go over a scenario together.

Say your beta and production builds share the bundle id com.example.myapp. On the device, they're the same app. That means they share the keychain, AsyncStorage, SQLite files, push tokens, everything. A tester installs the beta over their production install, and the beta happily reads production tokens from the keychain and starts firing requests at your beta backend with a production session. Or the other way around, which is worse.

Now say beta lives at com.example.myapp.beta. The OS treats it as a different app. Separate sandbox, separate keychain, separate storage. There is no code path, no forgotten if, no misconfigured env file that can leak production data into the beta build, because the operating system itself is the wall between them. An env variable is a promise; a namespace is a guarantee.

There's a second win here, and for your QA team it might be the bigger one: both apps install side by side on the same phone. The Expo docs call this out directly: each variant needs a unique Android application ID and iOS bundle identifier to enable simultaneous installations on one device. A tester can reproduce a bug in production, switch to the beta build, and verify the fix in under a minute, on the same device, with both sessions alive. No uninstalling, no logging back in, no "wait, which build was I on?" With a shared bundle id, every switch between environments destroys the other install and its state; with separate namespaces, comparing beta against production becomes a two-tap operation. Once your QA has worked this way, they will not let you go back.

Step 4: give each variant its own display name (and icon)

Two apps on one home screen, both called "MyApp" with the same icon? Your testers will file bugs against the wrong build within a week. So we want the beta to say "MyApp Beta" under a visibly different icon.

Here's where most guides tell you to change the name field per variant:

name: IS_BETA ? "MyApp Beta" : "MyApp",

Don't do that either. Why? Changing name changes every name reference in the app. Prebuild derives the native project name from it: the Xcode project name, the scheme, iOS folder names, Android module names. Change it and you've effectively renamed the whole native project, which means a full prebuild and a full native rebuild every time you switch variants. But all we need to change is the display name, the one string under the icon.

The thing we actually want to change is tiny: CFBundleDisplayName in Info.plist on iOS, and app_name in strings.xml on Android. That's exactly what the withDisplayName plugin from @vanenshi/expo-plugins does, and nothing else.

npx expo install @vanenshi/expo-plugins

// app.config.ts
const config: ExpoConfig = {
  name: "MyApp", // stays stable, native project never gets renamed
  // ...
  plugins: [
    [
      "@vanenshi/expo-plugins/display-name",
      { displayName: IS_BETA ? "MyApp Beta" : "MyApp" },
    ],
  ],
};

Now switching variants touches two plist/xml strings instead of the entire project structure. The home screen says "MyApp Beta", and your Xcode project doesn't even notice. You can verify it yourself after a beta prebuild:

$ grep app_name android/app/src/main/res/values/strings.xml
<string name="app_name">MyApp Beta</string>

$ /usr/libexec/PlistBuddy -c "Print :CFBundleDisplayName" ios/MyApp/Info.plist
MyApp Beta

Note the path: it's still ios/MyApp/, not ios/MyAppBeta/. The project structure stayed put.

The icon works the same way — it's just another config field, so branch it on the variant:

icon: IS_BETA ? "./assets/icon-beta.png" : "./assets/icon.png",

One field, both platforms.

In the example repo the production icon is blue and the beta icon is orange. Nobody taps the wrong app anymore.

Step 5: select runtime config by application id, not by env

So how does the app itself know which backend to talk to? The reflex answer is .env files. That doesn't work well in Expo: EXPO_PUBLIC_* variables get inlined into the JS bundle at build time — every process.env.EXPO_PUBLIC_X reference is replaced with its value when the bundle is created — and there's no real separation between environments. Each lifecycle (dev server, prebuild, the build itself) reads its own environment, so it's easy to bundle beta code with whatever env happened to be loaded at that moment. One stale shell variable and your beta build ships with the production URL baked in.

We already gave each variant a unique, OS-enforced identity in step 3: the application id. The app can ask the OS who it is, and pick its config from that. The same namespace that isolates the storage now selects the config, and the two can never disagree.

Install expo-application and make a config module keyed by application id:

npx expo install expo-application

// src/config/index.ts
import * as Application from "expo-application";

type AppConfig = {
  apiUrl: string;
  environment: "beta" | "production";
};

const configs: Record<string, AppConfig> = {
  "com.example.myapp": {
    apiUrl: "https://jsonplaceholder.typicode.com",
    environment: "production",
  },
  "com.example.myapp.beta": {
    apiUrl: "https://dummyjson.com",
    environment: "beta",
  },
};

const appId = Application.applicationId!;
const config = configs[appId];

if (!config) {
  throw new Error(`No config found for application id: ${appId}`);
}

export default config;

(The example repo uses two public fake-data APIs — JSONPlaceholder standing in for production, DummyJSON standing in for beta — so you can actually watch the two variants hit two different backends. In your app these would be api.myapp.com and api.beta.myapp.com.)

// anywhere in the app
import config from "@/config";

fetch(`${config.apiUrl}/todos/1`);

Walk through what just happened. There is no env variable to load, forget, or leak. The binary identifies itself through Application.applicationId, which per the docs is the application ID on Android and the bundle ID on iOS — the identity the OS installed the app under, unfakeable at runtime. If the app is com.example.myapp.beta, it gets the beta config, period. Build it with the wrong env loaded, build it on a colleague's machine, build it in CI at 3am: the mapping can't drift, because it isn't an input to the build at all. And the throw at the bottom means an unknown id fails loudly on launch instead of quietly talking to the wrong backend.

Two footnotes on that same mechanism:

Inside Expo Go, Application.applicationId returns Expo Go's own id (and on web it's null) — which makes sense once you remember what it is: the identity of the installed binary. So this setup assumes development builds, which you're already using if you run expo run:ios / expo run:android.
This file ships inside the JS bundle, so it's for config, not secrets. Anyone can extract these URLs from the binary. Real secrets stay on the server.

Since the app now knows its environment at runtime, gating beta-only features becomes a one-liner. The example app has a Debug tab and a debug screen that only exist in the beta build:

{config.environment === "beta" && (
  <NativeTabs.Trigger name="debug">
    <NativeTabs.Trigger.Label>Debug</NativeTabs.Trigger.Label>
  </NativeTabs.Trigger>
)}

No feature flag service, no env check — the OS-assigned identity drives it. And unlike an env-var check, it can't be true in the wrong binary.

Step 6: build it, locally

Now the payoff. No EAS queue, no cloud, just your machine (with the usual local build prerequisites: Xcode for iOS, Android Studio + JDK for Android):

# beta
APP_VARIANT=beta npx expo prebuild --clean
npx expo run:ios --configuration Release
npx expo run:android --variant release

# production
APP_VARIANT=prod npx expo prebuild --clean
npx expo run:ios --configuration Release
npx expo run:android --variant release

Notice APP_VARIANT only appears on the prebuild line. That's the whole point of step 2: the variable's only job is to decide what native project gets generated. Once ios/ and android/ exist, they are the beta app (or the production app) — bundle id, icon, name, everything baked in — and run:ios / run:android just build whatever is there. Setting the variable on the run commands would do nothing.

Wiping the native folders before regenerating matters here: layering a prebuild on top of existing files "may not produce the same results in some cases" — a half-beta, half-production Franken-project is exactly the failure mode we're avoiding. As of SDK 57, expo prebuild does a clean regeneration by default, so the --clean flag above is redundant — I keep it because it's harmless, it makes the intent explicit, and on older SDKs (where layering was the default) it's still required. Since the folders are gitignored and disposable, wiping them costs you nothing.

For distributable artifacts, prebuild first and then use the native tooling directly. On Android:

APP_VARIANT=beta npx expo prebuild --clean
cd android && ./gradlew assembleRelease
# apk lands in android/app/build/outputs/apk/release/

On iOS, open ios/MyApp.xcworkspace and archive from Xcode, or script it with xcodebuild archive if you're wiring this into CI.

Wrap the whole thing in package scripts and you're done:

{
  "scripts": {
    "start": "expo start --dev-client",
    "prebuild": "cross-env APP_VARIANT=beta expo prebuild --clean",
    "prebuild:prod": "cross-env APP_VARIANT=prod expo prebuild --clean",
    "ios": "expo run:ios",
    "android": "expo run:android"
  }
}

Two choices worth explaining. cross-env so the variable also works on Windows. And beta is the default — both in the bare prebuild script and as the fallback inside app.config.ts when APP_VARIANT isn't set. On a dev machine the build you crank out twenty times a day is the beta one, so it gets the short name, and production is the one you have to spell out with prebuild:prod. Wrong-way-around defaults are how production builds accidentally ship from a dev machine.

And if you do use EAS elsewhere, the same variant setup drives eas build --local too — one eas.json with a beta and a production profile, each setting APP_VARIANT, and eas build -e beta -p ios --local produces the same beta app on your own machine. The example repo ships those scripts as ios:beta:build / ios:prod:build.

One sanity check that makes the whole thing feel real — run the beta prebuild and look at what came out:

$ APP_VARIANT=beta npx expo prebuild --clean
✔ Finished prebuild

$ grep applicationId android/app/build.gradle
        applicationId 'com.example.myapp.beta'

$ grep PRODUCT_BUNDLE_IDENTIFIER ios/MyApp.xcodeproj/project.pbxproj | head -1
        PRODUCT_BUNDLE_IDENTIFIER = "com.example.myapp.beta";

Run it again without APP_VARIANT and both flip back to com.example.myapp. Two apps, one config file, zero cloud.

What we ended up with

Two apps that can live on the same phone. The beta cannot read a single byte of production data, because the OS won't let it. Runtime config is selected by the application id the OS installed the app under, so there's no env file that can drift between builds. Beta-only features are gated by that same identity. Switching between variants is one prebuild-time variable, and thanks to withDisplayName we get distinct home-screen names without ever renaming the native project. All of it runs on your laptop with the standard Expo CLI.

The complete working example is at vanenshi/expo-build-variants — clone it, run npm run prebuild && npm run ios, then npm run prebuild:prod && npm run ios again, and you'll have both variants on one simulator.

If you set this up and something breaks, or you want a third variant like staging (it's just another entry in the config map and another branch in app.config.ts), let me know.

Spec Anchor Development: The Methodology That Replaced Our AI Chaos

Amir Shekari — Wed, 20 May 2026 18:58:55 +0000

This is how we went from a team where everyone used AI their own way to one with a consistent, reviewable, onboardable codebase. Three methodologies, six months, one that actually stuck.

The problem with "everyone uses AI their way"

When AI coding tools started getting good, our team did what most teams do: let people figure it out themselves. Seniors, mids, two fresh graduates, everyone had a workflow, everyone was shipping, and nobody was producing the same kind of code.

The cracks showed up in review. Some PRs ignored project conventions entirely. Others were technically correct but bloated, AI-optimized for performance problems we didn't have. Commit histories were noise. Junior developers, who needed the most structure, had the least context to judge whether what the AI gave them was actually good.

This isn't really an AI problem. It's what happens when you hand a power tool to a team with no shared standards and assume it'll work out.

Step one: Rules

The first fix was the simplest. Back then Cursor was the dominant tool (this was before agent modes and Codex and Claude Code) and it had a rules system. I spent a day writing a real ruleset: naming conventions, commit format, complexity limits, anti-patterns we'd already seen, with examples of what good and bad looked like.

On the target repo, it worked immediately. PRs got more consistent. Reviews got faster. One technique worth knowing: ask the AI to compare its own output against the rules and flag deviations. Works well as a lightweight quality gate.

Worth noting: this isn't a Cursor thing. Every serious AI coding tool today has an equivalent. Claude Code has its CLAUDE.md, Windsurf has rules, Copilot has instructions, Gemini Code Assist has context files. The mechanism varies, the principle doesn't. Write shared rules, put them in the project, and every developer on every tool benefits from them.

The ceiling became obvious pretty fast though. Rules govern style and structure. They don't help when a developer asks the AI to build an entire feature in one prompt, which leads to bloated context, degraded coherence, and output that loses the thread halfway through.

Step two: SpecKit

SpecKit appeared around that time. The premise: break work into discrete specs before writing code, so the AI handles smaller, well-defined units instead of open-ended feature requests. I tested it personally for a week, got good results, and rolled it into our AI-assisted repos.

Then the overhead became the problem.

SpecKit's step count was more than we needed. Every feature added a new spec to an ever-growing list. After a few months it felt like a glorified plan mode. The list existed, nobody referenced it after the feature shipped, and it wasn't connected to any product-level decision. New engineers couldn't use it to understand why something was built a certain way.

We were generating documentation. We weren't capturing knowledge.

Why Spec Anchor Development

After more research I found Spec Anchor Development, a variant of SDD (Specification-Driven Development) where the spec isn't a step in a checklist. It's a persistent artifact, written before the build, used during it, kept after as a reference.

That's the actual difference from SpecKit. In SpecKit, specs accumulate. In Spec Anchor Development, each spec is tied to a specific feature or decision, lean enough to actually be read later.

What a spec anchor does in practice:

The developer (not the AI) defines what's being built before the AI touches anything
The AI gets a bounded scope: no guessing, no scope creep
When someone asks "why was this built this way," there's a document that answers it
When a decision affects the broader system, it feeds into an ADR

That last one changed things more than I expected. Once we configured the system to generate or update ADRs alongside spec anchors, we stopped losing institutional knowledge. New engineers could read the decision trail. Senior engineers stopped re-explaining the same architectural context in every code review.

OpenSpec

OpenSpec is the main tool for Spec Anchor Development. What makes it work for a mixed-seniority team is that it doesn't try to do too much. The spec template has what you need and stops there. Fast enough that developers don't resent writing specs, structured enough that the output is consistent across the team regardless of who wrote it.

We ran the full setup (OpenSpec with ADR generation) for three months. A few things that actually changed:

Code quality became consistent across seniority levels, not just in senior-owned repos
The mandatory spec step forced developers to slow down before coding. That sounds like friction. It caught scope problems that would have been code problems. Net positive.
Product and engineering could both read the spec layer, no translation required
Onboarding got easier. New engineers read specs and ADRs before reading code, and came in with actual context

What to take from this if you're setting up something similar

Rules first, but don't expect them to scale. Whatever tool your team uses, it almost certainly has a rules or instructions system. Use it. It's the fastest win available and worth doing regardless of what else you adopt. It won't solve the feature-scoping problem; it's not supposed to.

Test before you roll out. Run a personal evaluation for a week before putting a methodology in front of your team. The team tax for a bad methodology is real and slow to undo. SpecKit wasn't wrong for every team; it was wrong for ours.

A spec is not a ticket. A well-written spec anchor defines what the AI is building and what it isn't. That constraint is what stops the "huge prompt, degraded output" failure most teams hit on larger features.

The planning habit matters more than the AI workflow. The best thing this system did was change how developers thought before they opened their editor. Spending time in the spec phase forced actual thinking about scope, edge cases, and intent. The AI just made the habit systematic.

Don't skip ADRs. If specs don't connect to a record of why decisions were made, you'll reconstruct that context from scratch in every retro and every onboarding. It's the part teams skip first and regret most.

Why I Ditched SQS for Step Functions (and Ended Up Contributing to SST)

Amir Shekari — Mon, 11 May 2026 15:31:26 +0000

Every developer knows the "happy path"—that glorious moment when your code works perfectly on a small sample size. But when the "happy path" meets the reality of 100,000+ emails and strict API rate limits, things tend to break.

This is the story of how a bottleneck in my AI startup, Glim, led me to build and contribute the Step Functions component to the SST (Serverless Stack) ecosystem.

The Problem: The Gmail "Wall"

I was building Glim, an AI assistant designed to help users manage their chaos-ridden inboxes. We offered real-time filtering and a powerful bulk-cleanup tool that could archive or delete thousands of emails based on specific criteria like sender, date, or domain.

To make this work, I had to implement a full inbox sync. According to the Google API documentation, this is a two-step process:

Fetch a list of all email IDs.
Iterate through that list and perform a messages.get request for each individual email's full data.

The Math of the 429

Google’s rate limits are notoriously strict and follow a specific quota system. The limit consists of two primary factors:

Per-second Unit Limit: You are allowed 100 quota units per second.
Request Weight: Each type of request has a "weight." A messages.get request costs 20 units.

This means you can only fetch 5 emails per second (or roughly 300 per minute). If you violate this, Google hits you with a 429 Too Many Requests error and an exponential block that gets longer every time you retry too early.

Attempt One: A SQS Disaster

My first architecture was a classic serverless pattern: Lambda + SQS.

I bundled 20 email IDs into each SQS message. To respect the rate limits, I throttled the message publishing to one message per second. I set a 60-second visibility timeout, figuring that if a batch hit a 429, SQS would simply retry it a minute later based on standard AWS rules.

It worked... until it didn't.

For users with fewer than 40,000 emails, it was fine. But for power users with massive inboxes, the math fell apart. Multiple SQS batches would hit the rate limit simultaneously. The 60-second window wasn't long enough to clear the Google block, leading to more retries, more 429s, and a cascading failure that increased the block time exponentially. I realized I didn't just need a queue; I needed a State Machine.

The Solution: The "Scatter-Gather" Step Function

I needed a way to strictly control the flow of execution. If "Batch 1" hit a rate limit, the entire process needed to pause until that block cleared before "Batch 2" even started.

I decided to move to a Scatter-Gather pattern using AWS Step Functions. This allowed me to:

Fetch IDs: Fetch 500 IDs at a time (even fetching the IDs can hit limits once you pass 40k emails).
Strict Flow Control: Process the batch, respect the rate limit, then move to the next 500.
Software-Level Backoff: Implement an exponential wait step within the flow so that retries don't stack on top of each other at the API gateway level.

The Hurdle: SST Didn't Speak Step Functions

At the time, Glim was built entirely on SST (Serverless Stack). I loved the developer experience of SST, but there was a major missing piece: it didn't have a built-in component for Step Functions.

I had two choices: manually write raw Pulumi code (which would feel out of place in my clean SST codebase) or build a native SST component myself.

I chose the latter. I designed the component using a linked-node architecture. I visualized the state machine as a circular tree where each node connects the steps of the SF. I wrote the logic to compile this tree into the exact JSON format required for Pulumi (the backend of SST) and pushed it to AWS.

Giving Back to the Community

Once I had a working version, I didn't want to keep it in a silo. I forked the SST repository, integrated my new StepFunctions component, and used it to successfully fix the Glim inbox sync. It handled 100,000+ emails without breaking a sweat.

Seeing it work in production, I opened a Pull Request.

After several rounds of refinement, the code was merged. Today, that component, born out of a desperate need to sync 100,000 emails without hitting a Google rate limit, is available for everyone in the SST ecosystem to use.

Lessons Learned

Queues aren't Orchestrators: SQS is great for decoupling, but when you need to "stop the world" to wait for a rate limit, Step Functions are superior.
Understand the Quota: If I hadn't dug into the 20-unit weight of a messages.get request, I would have kept guessing why my Lambda was failing.
Scratch your own itch: The best open-source contributions come from solving real-world production problems.

Now, whether you're syncing a massive inbox or orchestrating a complex AI pipeline, you can do it natively within SST. Happy coding!

Boosting VS Code Productivity - Custom Labels for React Component Files

Amir Shekari — Fri, 05 Jul 2024 11:33:48 +0000

Ever felt like you're drowning in a sea of index.ts files? Trust me, I've been there. Working on a massive React project, I found myself constantly lost in a maze of identical-looking files. But then I stumbled upon a game-changer: VS Code's custom labels feature. Let me tell you how it transformed my coding life.

The Problem with `index.ts` Overload

Picture this: You're deep in the zone, juggling multiple components, when suddenly you need to find that one specific index.ts file. You open the search bar, and bam! A flood of indistinguishable results. Frustrating, right? That's exactly where I was until I discovered the magic of custom labels.

Enter Custom Labels

So, what's the deal with these custom labels? In a nutshell, they're VS Code's way of letting you personalize how file names appear in your editor tabs and search bar. For us React devs drowning in index.ts files, it's like throwing us a lifeline.

Setting Up Custom Labels Step by Step

1. Enable Custom Labels

First, you'll need to enable custom labels in your VS Code settings. Just add this line to your settings.json:

"workbench.editor.customLabels.enabled": true

2. Define Patterns for `index.ts` Files

Now, here's where the real magic happens. Add this bit to tell VS Code to replace those generic index.ts names with their parent directory names:

"workbench.editor.customLabels.patterns": {
  "**/index.{ts,js,tsx,jsx}": "${dirname}"
}

3. Customize for Specific Directories

If you're like me and have a specific folder where all your components live, you can target just that directory:

"workbench.editor.customLabels.patterns": {
  "components/*/index.{ts,js,tsx,jsx}": "${dirname}"
}

The Benefits of Custom Labels

Increased Readability: Instead of a sea of index.tsx tabs, you'll see "Button", "Header", and so on. It's like your editor suddenly learned to speak your language!
Efficient Searching: Searching for specific components became a breeze.
Reduced Mental Load: No more second-guessing which index.ts I was looking at.

So, fellow coders, if you're tired of playing "Where's Waldo?" with your index.ts files, give custom labels a shot. It's a small change that packs a big punch in your daily coding life. Trust me, your future self will thank you!

Building Safe and Dynamic URLs with TypeScript

Amir Shekari — Fri, 13 Oct 2023 19:58:13 +0000

When developing applications, one of the common tasks is constructing URLs, especially when they contain dynamic parts, like IDs. Ensuring the correctness of these URLs can be tedious, leading to potential runtime errors if not done right. This is where TypeScript can lend a hand.

The Need for urlConverter

Using string-based routes can be error-prone. Miss a single character or forget to replace a dynamic segment, and the whole URL can break. By using TypeScript, we can create a utility that helps in generating these URLs while ensuring their correctness.

Building the urlConverter Step by Step

1. Organizing URLs

One of the first steps is to have all URLs organized in one place. Enums in TypeScript provide an excellent way to do this:

export enum UserUrls {
  getUserUrl = "/users/[userId]",
  getMyUserURL = "/users/me",
  // other URLs can go here...
}

2. Extracting Dynamic Parameters

For URLs with dynamic parts, we need a way to recognize and replace them. A custom TypeScript type can help identify these parts:


type IsParameter<Part> = Part extends `[${infer ParamName}]`
  ? ParamName
  : never;
type FilteredParts<Path> = Path extends `${infer PartA}/${infer PartB}`
  ? IsParameter<PartA> | FilteredParts<PartB>
  : IsParameter<Path>;
/**
 * A very special type that parse a template string to it's object
 * source: https://lihautan.com/extract-parameters-type-from-string-literal-types-with-typescript/
 * type ParamObject = Params<'/purchase/[shopId]/[itemId]'>;
 * type ParamObject = {
 *      shopId: string;
 *      itemId: string;
 *    }
 */
export type Params<Path> = {
  [Key in FilteredParts<Path>]: string | number;
};

This type works to find any segment enclosed within [].

3. Confirming the Presence of Parameters

To ensure that if a URL requires parameters, they're provided, we can use another type:

type HasParams<Path> = Path extends `${string}[${string}]${string}`
  ? true
  : false;

This will check if a route needs parameters.

4. Creating the urlConverter Function

With all the above in place, we can now create our utility:

type AllEnums = UserUrls;

export const urlConverter = <Route extends AllEnums>(
  routeKey: Route,
  ...paramsArr: HasParams<typeof routeKey> extends true ? [Params<Route>] : []
) => {
  let route = routeKey as string;

  if (!route) {
    throw Error("Invalid route key");
  }

  const params = paramsArr[0];
  if (params) {
    Object.keys(params).forEach((paramKey) => {
      const value = params[paramKey]?.toString();
      route = route.replace(`[${paramKey}]`, value);
    });
  }
  return route;
};

Usage Example

Generating a reset URL with a given token can be done easily:


const getUserUrl = urlConverter(UserUrls.getUserUrl, { userId: 12 });
console.log(getUserUrl); // Outputs: `/users/12`

Conclusion

The urlConverter utility ensures that constructing dynamic URLs is straightforward and less error-prone. Leveraging TypeScript allows for catching potential mistakes at compile-time rather than runtime, resulting in more robust applications.

I hope this approach helps in your development journey, ensuring cleaner and safer URL generation with TypeScript.

Protect Production Database from Wrong Migrations

Amir Shekari — Tue, 25 Apr 2023 15:03:58 +0000

As a .NET developer, I had a close call when I applied a migration to my production database without changing the database connection string. I was mortified when I realized my mistake, but I quickly got to work finding a solution to prevent it from happening again.

That's when I came up with the idea to add a console message that displays the migration details before applying it. This simple addition gives me the chance to review the migration details and ensure that I am working with the correct database before making any changes.

With this new safeguard in place, I can breathe easy knowing that my production database is safe from accidental alterations. It just goes to show that sometimes the simplest solutions can be the most effective.

public class ApplicationDbContextFactory : IDesignTimeDbContextFactory<ApplicationDbContext>
{
    public ApplicationDbContext CreateDbContext(string[] args)
    {
        // ... Some code to generate dbContextBuilder
        var context = new ApplicationDbContext(dbContextBuilder.Options);

        // This is where magic happends
        var pendingMigrations = context.Database.GetPendingMigrations();
        Console.WriteLine("*********************************************\n");

        Console.WriteLine("This command is going to apply migrations with following details");

        Console.Write("ConnectionString: ");
        Console.ForegroundColor = ConsoleColor.Yellow;
        Console.WriteLine(connectionString);
        Console.ResetColor();

        Console.Write("Migrations:\n\t");
        Console.ForegroundColor = ConsoleColor.Yellow;
        Console.WriteLine(string.Join("\n\t", value: pendingMigrations.ToArray()));
        Console.ResetColor();
        Console.WriteLine();
        Console.WriteLine("*********************************************");

        Console.WriteLine("Do You confirm? (Y/N)");
        var userInput = (Console.ReadLine());

        if (userInput is "Y" or "y")
            return context;

        Console.ForegroundColor = ConsoleColor.Red;
        Console.WriteLine("Aborted!");
        Environment.Exit(1);
        return null;
    }
}

More info about the ApplicationDbContextFactory

Toggle your VPN connection with a shortcut, in Manjaro

Amir Shekari — Mon, 31 May 2021 15:55:55 +0000

This is a little script that allows you to toggle your VPN connection by running a bash script.
I mostly use it by assigning it to a shortcut (meta + v).