Forem: Bao Huynh Lam

3 cool things about the `create-vite` CLI you might not have known

Bao Huynh Lam — Sun, 08 Feb 2026 05:35:47 +0000

I wanted to learn how to make pleasant and interactive CLI like the creat-vite project scaffolding CLI, so yesterday I took a quick dive into the code of create-vite (note: not vite itself) to study what magical sauces they have and hopefully learn some cool new techniques along the way.

At a glance

Everything starts in the init function of the src/index.ts file

At a glance, we can see that the CLI progresses through 6 stages:

Get (or ask for) project name and target directory
Handle directory if exist and not empty
Get package name (if the project name at step 1 is an invalid NPM package name)
ASk users to choose a framework and variant
Ask user if immediate install is desired
Finally starts scaffolding folders and files

The main "ingredients" for this elegant experience includes:

mri library for working with CLI arguments
@clack/prompts library for displaying pretty interactive prompts
And picocolors for adding colors to the console log

Overall, the create-vite CLI is a pretty straightforward and simple tool. Diving into the code, I learned some interesting details.

Cool thing 1 - All the different CLI flags

On README, you might see that create-vite CLI supports the --template flag, but that's not the only one. Here are some more:

--overwrite / --no-overwrite: Should Vite overwrite if a non-empty directory already exists at your target location?
--immediate / --no-immediate: Marks your preference for step (5) - i.e. do you want immediate install and starting the Dev server after scaffolding?
--interactive (-i) / --no-interactive: Should Vite prompt you for answer, or assume default values? By default, the template is vanilla-ts if none is provided, and overwrite and immediate is false. The No-Interactive mode is useful when running create-vite as part of some unmonitored CI/CD pipeline, or if an AI agent is running commands.

Additionally, here are the full list of template names that you can pass into the --template argument:

// vanilla
"vanilla-ts",
"vanilla",

// vue
"vue-ts",
"vue",
"custom-create-vue",
"custom-nuxt",
"custom-vike-vue",

// react
"react-ts",
"react-compiler-ts",
"react-swc-ts",
"react",
"react-compiler",
"react-swc",
"rsc",
"custom-react-router",
"custom-tanstack-router-react",
"redwoodsdk-standard",
"custom-vike-react",

// preact
"preact-ts",
"preact",
"custom-create-preact",

// lit
"lit-ts",
"lit",

// svelte
"svelte-ts",
"svelte",
"custom-svelte-kit",

// solid
"solid-ts",
"solid",
"custom-tanstack-router-solid",
"custom-vike-solid",

// ember
"ember-app-ts",
"ember-app",

// qwik
"qwik-ts",
"qwik",
"custom-qwik-city",

// angular
"custom-angular",
"custom-analog",

// marko
"marko-run",

// others
"create-vite-extra",
"create-electron-vite"

Cool thing 2 - "Support" for AI agent

This is a fun little detail, but create-vite uses @vercel/detect-agent to determine if an agent is running the CLI. And if isAgent and interactive mode is enabled, the CLI will log a helpful message for the agent:

To create in one go, run: create-vite --no-interactive --template

Cool thing 3 - Some coding techniques

Here are some cool programming techniques I though were very interesting:

Determining the package manager via npm_config_user_agent ENV

Ever wondered how a CLI can determine what package manager you used, so it can continue using that in subsequent commands? It's all thanks to the npm_config_user_agent environment variable. Each package manager sets the variable accordingly (like how pnpm does here).

Example: You can run pnpm config get user-agent to get the full agent string:
```
pnpm/10.20.0 npm/? node/v20.11.1 linux x64
```
Then you can split by space and then by slash to get the package manager name.
Detect whether standard input is connected to a terminal or not via process.stdin.isTTY

The terminal input can also be piped in (like cat data.txt | xargs pnpm create-vite), in which case interactivity won't be possible. As a result, the CLI only enables interactive mode if isTTY is true.
Handling Control-C gracefully

After every prompt, I noticed that there is always a check to see if the user has cancelled the command so that we can gracefully display the message "Operation Cancelled".
```
if (prompts.isCancel(projectName)) return cancel()
```
This technique feels so obvious in retrospect (and the @clack/prompts creator also recommends so), but seeing how it is employed in production-ready code base somehow really cements it for me.

In summary - lessons I learned

mri, @clack/prompts, and picocolors are a quick combo to create a very pleasant CLI
Use process.env.npm_config_user_agent to detect what package manager was used
If you're using @clack/prompts: Check prompts.isCancel to handle control-C gracefully

Typescript and HTML attributes in various frameworks

Bao Huynh Lam — Thu, 02 Jan 2025 00:28:46 +0000

If you have worked with Typescript in a JavaScript framework - React, Vue, Solid, or Svelte - then you might have needed/will need to create wrapper/mirror components that encompasses native HTML elements.

For example: An enhanced <Link> wrapper over the <a> element. Or a custom <Button> component that behaves like a <button> - and be able accept all relevant attributes like type, style, aria-, etc. - but also allow passing in your own custom variant prop.

In such case, you would want to Typescript your component's props to extend the list of attributes that the underlying HTML component accepts.

Fortunately, all frameworks offer type helpers to achieve this.

React

React provides multiple helpers, including ComponentProps, or the more specific ComponentPropsWithoutRef if you don't want to accept a ref prop. They both requires one type parameter which is a string corresponding to an HTML element.

interface ButtonProps extends React.ComponentPropsWithoutRef<"button"> {
  specialProp?: string;
}

export function Button(props: ButtonProps) {
  const {specialProp, ...rest} = props;
  return <button {...rest}>{Button Text}</button>
}

Solid

Solid provides similar a helper with its JSX.ComponentProps type

import { ComponentProps, splitProps } from "solidjs"

interface ButtonProps extends ComponentProps<'button'> {
  specialProp?: string;
}

export function Button(props: ButtonProps) {
  const [local, others] = splitProps(props, ['specialProp']);
  return <button {...others}>{Button Text}</button>
}

Svelte

Svelte takes a bit different approach where you can import the direct interface from "svelte/elements" without using a type parameter

<!-- ButtonComponent.svelte -->
<script lang="ts">
  import { HTMLButtonAttributes } from 'svelte/elements'
  interface ButtonProps extends HTMLButtonAttributes {
    specialProp?: string;
  }

  const {specialProp, ...rest}: ButtonProps = $props()
</script>

<button {...rest}>Button Text</button>

Vue

Vue has automatic "fallthrough" attribute, so any prop that you don't explicitly define will automatically get passed through the root element in the template. No Typescript involved!

<script lang="ts">
  import { defineComponent } from 'vue';

  export default defineComponent({
    name: 'MyComponent',
    props: {
      customProp: String, // Just need to define the custom prop
    },
   });
</script>

<template>
  <!--
   Attributes not matching the `props` object above
   will automatically fall to our button
  -->
  <button>Button Text</button>
</template>

Learn programming by peeling back layers of abstractions

Bao Huynh Lam — Wed, 10 Apr 2024 02:35:41 +0000

Learn by peeling back layers of abstractions

Here’s my programming hot take 🌶️: Libraries are amazing, but they might also make you and me “dumber”. Let me explain.

Preface: Libraries, frameworks, and code sharing in general is absolutely fantastic. The programming world wouldn’t have existed if we weren’t able to utilize other’s well-written and battle-tested code and everyone had to reinvent the wheels every time. Efficiently using the right libraries for the job is one of the best ways to quickly and securely deliver an impactful product.

However, recently I realized that I have been using so many libraries mindlessly without considering what exactly do they abstract. Some libraries masterfully cover away so many painful complexities that using them feel so easy-breezy that I began to take them for granted.

And that is dangerous because not always will you have access to these libraries. Companies may have strict permission policies that prevents you from installing certain tools. Moreover, not understanding how the libraries work - what are they good at and what are their shortcoming - hinder my abilities to put them into a bigger picture. When tasked with a similar but more complex situations, I won’t be able to identify and comprehend how a library can help or what are some limitations I need to be aware of. When a new technology revolutionizes the space, I won’t be able to contrast and compare them with each other to recognize why this new thing is so valuable.

That’s why I have been striving to dig deeper and understand more about the mechanisms at work and let curiosity guide my next journeys. And I definitely encourage everyone, especially beginners to do the same.

You don’t have to know it all to the tiniest details, but having a general idea how the technology fits into the big picture helps a lot.

Seek to (and struggle to) learn by peeling back layers of abstractions.
Consider building projects without your favorite libraries.

If you have been building in React/Vue/Angular, try building an app with vanilla JavaScript and/or traditional server-rendered templating so as to see what areas JavaScript framework actually helps.
If you have been using an ORM, try making a small project using raw SQL
If you have been doing AI with PyTorch and Hugging Face, consider re-building a classic ML architecture using more native technologies (I learned a lot from a school project where we built a simple neural net with just numpy)
Or just start reading, listening, and watching more on the topics of what’s going on under the hood

I have found these basic projects to make me grow a lot by helping me understand what exact "pains" my libraries are abstracting away and help me be less confused about which features are natively-provided vs. library-specific.

Let me know if you have been doing the same thing to. Would love to hear your success stories!

Explaining JavaScript Promises with money 💵

Bao Huynh Lam — Sun, 09 Jul 2023 00:32:57 +0000

What are Promises

JavaScript Promise is similar to how they mean in native English:

A promise/assurance that something will happen in the future, some value will return in the future, but not now

Imagine you are JavaScript, and your friend promises they will give you $5. You know your friend will give $5 sometime in the future, but not now, so you queue that task back into your memory, and continue doing your thing.

Why do we need Promises anyway?

Promise is part of the non-blocking asynchronous JavaScript workflow. Because JavaScript is single-threaded, we don't want certain actions to block the entire main thread. You don't want data fetching to block rendering the HTML. You don't want submitting requests to a server to pause the GIF playing in the background.

That's why JavaScript need a way to schedule some tasks that take time to the background and check back on them later, but not now. Prior to Promise, JavaScript uses callbacks, but that leads to huge problems of callback hell, so Promise is created as a more ergonomic solution.

Promises can be a chain

Imagine that immediately after your friend's promise, your mom demands $5 from you. Can you give it to her now? No you can't, because you don't have it, but you can schedule that: wait until after your friend give you $5, then you can give it to your mom. And that's how the Promises chain happens.

Friend gives you $5
  <-- Then you give it to mom
  <-- Then your mom praises you
  <-- Then you are happy

Note that actions that depend on the value of a Promise get chained into a big Promise chain, and the whole thing becomes a big Promise. These scheduled things will happen sometime in the future, but not now. Once you are in Promise land, you can continue the chain, but can't go backout to the synchronous world.

Promises can have three states

Note that a Promise can have three states: Pending, Resolved, and Rejected. While waiting, the Promise is pending. If your friend's promise continues smoothly, the $5 is given successfully, then the Promise is resolved. However, if any errors happen in the Promise chain (your friend lost the money to the wind), it becomes Rejected, and will error out.

How to work with JS Promise & code samples

You can create a Promise yourself with the Promise constructor, which takes in a function that decide how to resolve or reject the promise.

const p = new Promise((resolve, reject) => {
  const today = new Date();
  // If at the time this Promise is invoked, it's Saturday
  if (today.getDay() === 6) {
    resolve("Happy day"); // Then successfully returns string
  } else {
    reject("Not Saturday") // Else error out
  }
})

You can also quickly create a Promise that automatically resolves with Promise.resolve(), or a Promise that automatically rejects with Promise.reject(), which are mostly used for testing purposes.

Most of the time, you won't need to create a Promise yourself, and instead work with Promises given by other libraries like in fetch, axios, or bcrypt. You can chain any dependent action with .then(), and catch error with .catch()

// Schedule a Fetch promise
fetch("https://example.com")
  .then(value => document.title = value.toUpperCase())
  .catch(err => { console.error(err); document.title = "Error" } )

Note that Promises are queued into the background by JavaScript to be checked back later, so the code below will not work like you expected, as you would be mismatching synchronous code and asynchronous code.

let title = undefined
// After promise is resolved, `value` will be assigned to `title`
// But for now, JS will queue this task onto the background, and
// continue immediately with the next line
newValuePromise().then(value => title = value)

// Therefore, even if you console.log here, you'd still get `undefined`,
// no matter how fast or instant your Promise is
// Once you are in Promise land, you can continue the chain, but
// can't go back out to the synchronous world.
console.log(title)

One thing to watch out for is that only the value you return from the previous .then is available to the next .then. If you forgot to return any value, the next .then won't have it.

fetch("https://example.com")
  .then(value => {
    return value.toUpperCase()
  })
  .then(upperCaseVal => {
    console.log(upperCaseVal)
  })
  .then(value => {
    // Since the previous `.then` only console.log and did not
    // return any value, this `.then` does not have any value    
    console.log(value) // undefined
  })

Async and Await

Async/Await is another syntax to work with Promises besides .then(). If you tag your function with async, then you use await instead of .then to continue the promise chain

async function handleResponse() {
  const response = await fetch("https://example.com");
  if (response === "happy") {
    // If happy response, then add a new diary entry
    const anotherResponse = await fetch("http://diary.com/new");
    console.log(anotherResponse);
    return anotherResponse;
  } else {
    return "normal day";
  }
}

is equivalent to

function handleResponse() {
  fetch("https://example.com").then((response) => {
    if (response === "happy") {
      return fetch("http://diaray.com/new").then((anotherResponse) => {
        console.log(anotherResponse);
      });
    } else {
      return "Normal day";
    }
  });
}

You can see how async/await really simplify the code flow and nesting, and is much more readable.

Note that the async function still returns a Promise. In an async function, it might look like you are writing normal synchronous JavaScript, but async/await is just a syntactic sugar over .then(), and whatever value you return from an async function will be wrapped into a Promise.

Some random caveats

`setTimeOut()` is actually not a Promise

You will notice that setTimeOut is used a lot in an asynchronous settings, either to stimulate Promise taking time in tutorials, or to schedule something that JS will come back to in the future. However, setTimeOut() actually does not return a Promise itself, and instead works with callback function (old-school style). You can convert setTimeOut() to a sleep() function that returns a Promise like below:

// Making setTimeOut return a resolved Promise after `ms` time
function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function test() {
  await sleep(1000);
  document.title = "Awoken after 1000ms sleep";
}

// Or without async
sleep(1000).then(() => document.title = "Changed")