DEV Community: Raymond

Asynchronous Javascript

Raymond — Tue, 29 Apr 2025 17:02:50 +0000

What is synchronous javascript?

When talking about javascript, you may have come across a term called the javascript interpreter or javascript engine. If you haven't, the interpreter is basically just your browser and how it reads and evaluates javascript (or node if executing javascript on the server). The interpreter parses (fancy word for "reads") your javascript code in a top down order. Think of this in the same way you would read a book. You start reading (at least in most languages) from left to right and top to bottom.

Consider this code snippet:

console.log('hello')
console.log('world')
console.log('!')

// hello
// world
// !

In javascript, the next line of code will not be allowed to run until the previous line has completed and this is referred to as blocking code. So in our example, the log for 'world' will not run before the log 'hello' because of its order.

What is asynchronous javascript?

Asynchronous javascript is code that can run out of order of the original flow of code.

Consider this snippet:

console.log('hello')

setTimeout(() => {
  console.log('world')
}, 1000)

console.log('!')

// hello
// !
// world

setTimeout is an asynchronous function that takes a function as an argument (a callback) and a time (in milliseconds) that will act as the amount of time to wait until it can execute the callback passed.

Looking at the example, the interpreter starts to parse the code from top to bottom. It first logs hello to the console. It moves on to the next line of code and sees that there is a setTimeout which is asynchronous. It determines that we don't need to wait for this line to finish. It registers this callback in a different queue for execution (beyond the scope of this article), so we can move on to the next line to execute. It then logs the ! to the console. Now, at minimum 1000 milliseconds (1 second) has passed. It can now execute the callback in setTimeout and logs world to the console.

Asynchronous code is non-blocking, meaning that the interpreter doesn't have to wait for the async code to execute for it to move to the next line for processing. Think of it like asking someone on a date when you were in high school (might be showing my age here). You say on a note something along the lines of "Will you go out with me?" and a few boxes that say

[] yes ✅
[] no ❌
[] maybe ❓

You pass it off to that person and and go about your day until they give it back with a reply (and hopefully you didn't get rejected 😬). This is, in effect, an asynchronous operation.

Callbacks

To understand what a callback is, you have to understand that functions can take in arguments. These arguments can be any javascript type including other functions. At first, callbacks can be a bit tedious to understand, but once it clicks... you'll have a much easier time with programming in javascript.

Function declarations and expressions

There are a few ways to declare a function. One is called a function declaration where you use the function keyword.

function doSomething(){}

The other is a function expression where it is declared as a variable with let, var, or const

const doSomething = function(){}
//or
const doSomething = () => {}

Parameters can be added to the function to be used as arguments. To be a parameter is when a function declaration or expression is being created (defined).

// they are **parameters** during function declaration
function add(param1,param2){ return param1 + param2 }

To be an argument is when the function is being invoked (called).

// they are **arguments** when the function is called
let arg1 = 1
let arg2 = 3
add(arg1,arg2) // 4

Think of parameters as local variables to the function. Whatever is passed as an argument becomes the value of the parameter that was defined. Essentially a placeholder until the function is invoked.

Defining a function with a callback

Why is it important to know about function declarations and function expressions? That is where you will understand how a callback is created and how arguments are passed to them.

When you declare (define) your function you can add a callback parameter to the function that can be used.

function doSomething(callback){
  callback('hello world')
}

In the snippet above, we are creating a doSomething function declaration. The parameter (callback) is expected to be a function. Here, we've named it callback but could be any name you decide to give it. In the doSomething function body we are calling the passed callback function with a string value as an argument ('hello world'). Now we can use the doSomething function and pass in a callback function as an argument.

// hello could be changed to anything
doSomething((hello) => {
  console.log(hello) // "hello world"
})

Since the string was passed as an argument to the callback function we can use that value inside of the callback function's body. We simply log the hello argument to the console which logs the string "hello world". The hello variable can be named anything you want to name it. It is important to understand here that the value of that argument, in this context, will always evaluate to the string provided in the doSomething function definition's callback ("hello world").

This understanding in callbacks can help you better understand that when some library documents a callback and has arguments to them, there isn't much "magic" actually happening. Somewhere in the function definition someone wrote code to pass an argument to that callback. That argument (or arguments) will always be the same object, number, boolean, or whatever it may be. Though the values may change, the expected type typically won't.

The Old Ways

At some point during the evolution of development, async code was typically handled through a series of callbacks. This created readability issues especially when you started deeply nesting callbacks for asynchronous operations:

doSomething((value) => {
  doSomethingElse(value, (value2) => {
    doSomethingMore(value2,(endResult) => {
      console.log(endResult)
    })
  })
})

Based on the example above imagine that you had some operation that you had to perform where you couldn't complete some task until multiple other tasks were completed before it. This would force you to nest your functions as in the example. If you have 5-10 tasks that need to be completed and calculations that needed to be performed on some of them before passing them on, this could get pretty messy pretty quickly.

Enter Promises

Promises were introduced in ES6 of javascript in 2015. This simplified async operations by providing a more readable way to handle callbacks using method chaining. Some of the methods for the Promise object are .then(), .catch() and .finally().

If you wanted to define a function as a promise we would need to return a promise from it.

function valueAfter2Seconds() {
  return new Promise((resolve) => {
    setTimeout(() => resolve(10), 2000)
  })
}

In the example, we are defining a function valueAfter2Seconds. In the function body we are calling new Promise and returning it. The promise constructor takes a callback function. The arguments to the callback are resolve and reject. Both are callback functions as well. We are creating a delay of 2 seconds and resolve with a value of 10. Whatever value you would like to resolve gets passed as the argument to the resolve callback. Likewise, if using the reject callback, it will raise an error with the rejected value passed to it.

Now we can see how to get the value from the promise.

valueAfter2Seconds()
  .then(value => console.log(value))
  // 10

When valueAfter2seconds runs, it immediately returns a promise. The state of that promise during initial execution is pending. The .then method waits for the resolved value from the promise. .then accepts a callback function as its first argument. The callback's argument is the value passed to the resolve callback. Once 2 seconds has passed, the .then function will receive the value and log 10 to the console. In the event more operations need to be done we can return a value from .then and pass it to the next one in the chain

valueAfter2seconds()
  .then(value => {
    console.log(value) // 10
    return value + 5
  })
  .then(newValue => {
    console.log(newValue) // 15
    return newValue - 10
  })
  .then(otherValue => console.log(otherValue)) // 5

A bit of a contrived example, but hopefully it makes the point.

You would typically handle any errors within the .catch method. Since promises are asynchronous, async code is taken out of the original execution context (how code is parsed), the original error cannot be handled in synchronous code. The error will be lost. In the context of node, this would raise an uncaught exception error and cause the server code to crash. This is one of many reasons why handling async errors is important.

Alternatives for promise execution

Some alternatives to consider execution order for async code is to use built-in promise methods like Promise.all, generator functions, or using async/await which was introduced to javascript in 2017.

Normal individual promise handling

Lets assume that we have some tasks to run:

function task1() {
  return new Promise(resolve => {
    setTimeout(() => resolve(1),1000)
  })
}

function task2() {
  return new Promise(resolve => {
    setTimeout(() => resolve(2),500)
  })
}

function task3() {
  return new Promise(resolve => {
    setTimeout(() => resolve(3),2000)
  })
}

and we want to run those in a specific order where each one logs a value in numerical order. The first thought would be to do something like this:

task1().then(value => console.log('task 1', value))
task2().then(value => console.log('task 2', value))
task3().then(value => console.log('task 3', value))
// 'task 2' 2
// 'task 1' 1
// 'task 3' 3

The issue above is that the order in which they are resolved may be different based on the time each are completed. Since the time for task 2 is 0.5 seconds it will log first, then task 1, and last is task 3. While this looks somewhat like it should execute in order, because of these times that the promises resolve, they don't. Let's consider this code instead:

task1()
 .then(value => {
  console.log('task 1', value)
  return task2()
 })
 .then(value => {
  console.log('task 2', value)
  return task3()
 })
 .then(value => {
  console.log('task 3', value)
 })

// "task 1" 1
// "task 2" 2
// "task 3" 3

A promise waits to be resolved before passing the resolved value to the .then method. A promise can, then, be returned from a .then method and will resolve before being passed down the chain in the next .then method call. Above we are calling task1() and chaining a .then. Once the value is resolved it's passed to the callback where it is logged ("task 1" 1). We then return the promise task2() from the first .then. Once task2() is resolved, its value is passed to the next call of .then and the value is logged to the console ("task 2" 2) and so on.

Promise.all

The promise object comes with a method that allows you to return resolved values in order... Promise.all(). The method takes an array of promises as a function. So we can pass the called functions in an array to the method:

function allPromises() {
  return Promise.all([task1(), task2(), task3()])
}

allPromises()
  .then(values => console.log(values))
  // [1,2,3]

When all promises have been resolved, the promise that is returned from allPromises will be an array of values in the order they were passed in which outputs the order we expect. Even though the order is preserved, task2 will still, technically, resolve before the other two functions. One issue with using this method is that if one of those promises rejects (throws an error) then all promises in the array reject. If you want something where you would like any resolved values and handle the rejected value separately, then Promise.allSettled should be considered.

Using Generators

One alternative to running promises in a specific order without chaining a .then to everything is to use generator functions. They follow the iterator protocol by providing a next method and a done value that indicates if the iterations are complete. To define a generator function, you use the function keyword followed by an asterisk (*).

Generators use a keyword yield that stops execution and yields a value to be returned from the generator. When the last yield expression is reached or a return value is reached, the done value of the generator is flipped from false to true and can no longer be called with the next() method of the generator. When a yield keyword is encountered and the value returned from it, the execution of the generator is stopped while preserving the variable bindings for the next execution (basically a fancy way of saying the inner scoped variables aren't reset or lost, but preserved).

We can start by making a generator function that yield promises:

function* generator() {

  const task_1 = yield task1()
  console.log(task_1)

  const task_2 = yield task2()
  console.log(task_2)

  const task_3 = yield task3()
  console.log(task_3)

  return task_3

}

Here we are defining a generator function named generator for lack of a more creative word. Each async function is yielded providing a place for execution to stop and return a value. When the generator's next method is called it will yield the next value and continue on that pattern until a return is reached or there is nothing left to yield.

Now we can create a function that runs the generator and yields all values in the order they were defined in the generator.

function runGenerator(genFn) {
  const gen = genFn()

  function step(arg) {

    const result = gen.next(arg)
    if(result.done) return result.value

    return Promise.resolve(result.value).then((value) => step(value))
  }

  step()
}

We will create a runGenerator function that takes in a generator reference as an argument. We then store the value to the genFn() call in a variable called gen short for generator. Next we create a function called step inside of the runGenerator function body. The step function will take in an argument arg which will be the resolved value of the yielded promise in the generator.

We create a base case checking if the result.done is true. If it is, the generator is done executing and we can return the value from the final execution of the generator. Otherwise, we resolve a promise with the result.value. Remember that the value is a promise. Once the promise is resolved, it will pass the resolved value to the .then method. For clarity, I am passing in a callback to .then which explicitly calls the step function with the resolved value to give it back to the generator. You could just pass the reference to .then ie: .then(step).

We have to pass the resolved value back to the generator so it can pick up execution with the resolved value of the promise. Otherwise it will log undefined. The step function is executed recursively until the result.done value is true.

We then invoke the step function within the runGenerator function. Since this function is void, we can just let it log the results.

runGenerator(generator)

// 1
// 2
// 3

Async and Await

So why learn about generators? You likely don't see them too often. Generators can solve a host of issues with asynchronous javascript. You could use them for pagination, infinite scrolling, or possibly for server code that might require such a thing. Ultimately async and await are kind of an abstraction around generator functions, yet are much cleaner and simpler to implement. Consider this function:

async function actLikeGenerator() {
  const task_1 = await task1()
  console.log(task_1)

  const task_2 = await task2()
  console.log(task_2)

  const task_3 = await task3()
  console.log(task_3)

  // 1
  // 2
  // 3
}

According to the mdn docs,

Using await pauses the execution of its surrounding async function until the promise is settled (that is, fulfilled or rejected). When execution resumes, the value of the await expression becomes that of the fulfilled promise.

What does that mean? When you define an async function with the async keyword. You can use the await keyword inside the function body. The await keyword acts similar to the yield keyword in a generator function. It will pause the execution of the function until the promise is resolved with a value. Once the promise is resolved, the value is unwrapped (like using a .then).

So in the example above, when the first await keyword is encountered, the function pauses execution and waits for task1() to resolve. Once task1() resolves, the value is assigned to the variable task_1 and moves to the next line and logs 1 to the console. After logging, we move to the next line and encounter another await keyword. We pause again until task2() is resolved. We, again, continue execution and assign the resolved value to task_2 and log it to the console (2) and so on. This provides a much cleaner way of reasoning through asynchronous code.

Conclusion

By understanding how functions are defined will help you better understand how callbacks are defined and used. This isn't just useful for asynchronous javascript, but programming in general. The introduction of promises helped to make asynchronous operations in javascript more manageable, while adding async/await helped to make it more readable. By understanding generators, you can better visualize, roughly, how async/await works under the hood. Let me know your thoughts in the comments!

Adding A Feature to Cypress.JS

Raymond — Mon, 10 Feb 2025 16:41:13 +0000

Cypress.js

Cypress now has a new feature for automatic browser launch after passing the --browser flag alone with a good browser name or path! This is a breakdown of the contribution that brought it to life!

Cypress is a testing framework used to perform end to end (e2e) testing and component testing. It provides a wide range of support for multiple frontend frameworks including Vue, React, and Angular. It has a healthy ecosystem and has over five million downloads a week. Multiple businesses use it in their CI pipeline for test automation.

The Cypress repo is a package-based mono repo that is handled by Lerna. Lerna is powered by nx under the hood. This allows you to manage workspaces in the root of the repo from the command line and install dependencies that are shared between packages. yarn is used as the package manager for dependencies.

Cypress uses Javascript and Typescript as a full stack language. Their frontend components are shared between their launchPad and another frontend application. The launchpad is used with Electron which is a tool for creating desktop applications in Javascript. They use node to set up a server and add a series of caching mechanisms utilizing the file system on the host machine for user preferences, projects, etc. Their frontend is in Vue.js and uses Urql for their GraphQL client. They utilize a series of tools for GraphQL to create GraphQL object types, queries, mutations, and subscriptions.

Data Context

The data-context workspace is the core of the application. It is the single source of truth for the data floating around. It uses some Typescript decorators to cache values. It's also used to inject it's this value in a host of other APIs. It utilizes a singleton pattern to be consumed by the application. This data context is used as the main GraphQL context for resolvers in the app.

The issue

As the application stood, you could pass --project <project-path>, --<testing-type> (component or e2e), and --browser <browser-name-or-path> flags and have the application automatically launch the browser. The caveat was that you had to pass all of those flags together from the cli and could not pass the --browser flag alone. If passing that flag alone, you would reach the view for browser selection. The browser would be highlighted showing the passed browser, but would not automatically launch it.

Specs

The use case for the issue was to:

have a browser launch automatically after selection of project and testing type in the application when passing --browser <name-or-path> alone.
If name or path was invalid it would render the already created error message without automatically launching the last cached browser.
- the user would have to dismiss the warning and select the browser from the GUI
- or the user would have to start the process with a good name or path from the cli
If the name or path was correct, it would only launch once.

Making Some Changes

ProjectActions.ts

The data-context utilizes several different APIs to handle different function calls. These APIs are referred to as actions. They are class based and provide functionality based on data received from other APIs. The ProjectActions class is responsible for (given a browser, project, and testing type) launching the browser and given project in its respective test mode.

export class ProjectActions {
  // keep track of launchProject calls
  private globalLaunchCount = 0
  constructor (private ctx: DataContext) {}

  private get api () {
    return this.ctx._apis.projectApi
  }
  // allow the launch count to be read
  get launchCount() {
    return this.globalLaunchCount
  }
  // ...
  async launchProject (testingType: Cypress.TestingType | null, options?: Partial<OpenProjectLaunchOpts>, specPath?: string | null) {
    // code omitted for brevity

    await this.api.launchProject(browser, activeSpec ?? emptySpec, options)
    this.globalLaunchCount++

    return
  }
  // ...
}

The main focus here was to have a way to track when launchProject was called. Since there will be two different scenarios for the browser to launch (i.e. passing 3 flags or passing 1 flag), globalLaunchCount will be the differentiator. In the event that all 3 flags have been passed by the time we land on the browser selection screen we don't want the function to launch again. So we increment the value after the this.api.launchProject call just before the return. If this doesn't make sense just yet, that's ok, it will soon.

LocalSettings.ts

The GraphQL layer uses a tool called GraphQL Nexus. It provides a declarative way to create schemas, among other things, in GraphQL. When you define a type with nexus, it auto-generates type-documents for Typescript type-safety (super nice feature).

export const LocalSettingsPreferences = objectType({
  name: 'LocalSettingsPreferences',
  description: 'local setting preferences',
  definition (t) {
   // ...
    t.boolean('shouldLaunchBrowserFromOpenBrowser', {
      description: 'Determine if the browser should launch when the browser flag is passed alone',
      resolve: async (_source, _args, ctx) => {
        try {
          const cliBrowser = ctx.coreData.cliBrowser

          if (!cliBrowser) {
            return false
          }

          const browser = await ctx._apis.browserApi.ensureAndGetByNameOrPath(cliBrowser)
          const shouldLaunch = Boolean(browser) && (ctx.actions.project.launchCount === 0)

          return shouldLaunch
        } catch (e) {
          // if error is thrown, browser doesn't exist
          return false
        }
      },
    })
   // ...
  },
})

Let's cover what's going on here. objectType is a function coming from nexus. It allows you to create a GraphQL object type with a name and a definition and optionally a description. The argument to the definition method is an object (t) that provides helper methods to define fields, scalars, and resolvers. t.boolean indicates a boolean scalar. This helper method takes one required argument (a field name) and an optional second argument (an object). Here, shouldLaunchBrowserFromOpenBrowser (I know, specific) is the field name for the LocalSettingsPreferences object type and is intended to resolve to a boolean value.

The resolve method takes in 4 arguments. If you would like to have a quick rundown of them, you can find a quick diagram here. For the sake of this, we are just concerned about the 3rd argument... the context. This is the data-context passed in on the server during initialization and becomes available to all resolvers. The cliBrowser is the browser (name or path) that was passed in the cli. If nothing was passed we can return false right away indicating we should not launch the browser. If it does exist, the data context provides a nice async function from the browser API, ensureAndGetByNameOrPath, that can attempt to find the browser on the machine. This helps with two things:

Code reuse-ability. No need to reinvent the wheel. You know it exists because this was already baked in before you got here.
Provides a way to tell if the actual browser (name or path) is valid.

If the browser does exist, we can convert the value to a boolean and also check that the launchProject function hasn't been called based on the launchCount being strictly equal to 0 allowing it to resolve to true other wise it resolves to false. If the browser doesn't exist, then the function throws an error. We can catch it and return false.

OpenBrowser.vue

Let's understand some code that was already present.

gql

This function is supplied by Urql to generate DocumentNodes. Here, this function is creating a document node called OpenBrowser_LaunchProject which is a mutation.

gql`
mutation OpenBrowser_LaunchProject ($testingType: TestingTypeEnum!)  {
  launchOpenProject {
    id
  }
  setProjectPreferencesInGlobalCache(testingType: $testingType) {
    currentProject {
      id
      title
    }
  }
}
`

$testingType is an argument to the OpenBrowser_LaunchProject document node that is an enum. The mutation to launchOpenProject corresponds to a server mutation of the same name and is intended to launch the current project with the current testing type. The other mutation is to set the current testing type in a global cache.

launchOpenProject

This will be the mutation used to launch the project

const launchOpenProject = useMutation(OpenBrowser_LaunchProjectDocument)

useMutation is a hook from Urql that abstracts away some of the common needs of creating mutations. We pass the OpenBrowser_LaunchProjectDocument that is imported from generated document nodes based on the gql definition of OpenBrowser_LaunchProject.

launching

This is a Vue ref.

const launching = ref(false)

refs are values to be directly mutated. Unlike React when setting or updating state, the value can be directly updated or mutated to trigger component updates based on reassignment of the launching ref's value property. The value property is the current value of the ref. In this case it is initialized to false.

launch

This function was already present. It was used to emit an event called @launch from a child Vue component form submission to launch the project. The syntax @launch is a custom event defined as a v-on handler. You can learn more about events in Vue here

const launch = async () => {
  const testingType = query.data.value?.currentProject?.currentTestingType

  if (testingType && !launching.value) {
    launching.value = true
    await launchOpenProject.executeMutation({
      testingType,
    })

    launching.value = false
  }
}

The launch function finds the current testingType based on a query. If there is a testing type selected, and the launching ref's value is false, we set the launching.value to true which triggers a component update for a loading state for the UI. It executes the launchProject.executeMutation method of the useMutation hook created earlier and takes in the required testing type as the argument for the mutation. If that launch occurs or not, the component state needs to be updated to reflect the function has completed and set launching.value to false.

OpenBrowser_LocalSettings

This is a newly created document node

gql`
query OpenBrowser_LocalSettings {
  localSettings {
    preferences {
      shouldLaunchBrowserFromOpenBrowser
    }
  }
}
`

This document node's sole responsibility is to grab the value for shouldLaunchBrowserFromOpenBrowser which will either be true or false.

lsQuery

lsQuery uses another hook from Urql. This was a newly created query. As for the naming, I could have been a little more explicit to state that this was localSettingsQuery and probably should have done so.

const lsQuery = useQuery({ query: OpenBrowser_LocalSettingsDocument, requestPolicy: 'network-only' })

Like the mutation, we pass in a document node for the query. The thing to note here is the requestPolicy property. During initialization of the app and the Urql client, there is an in-memory caching policy set up to prevent unnecessary network requests. It provides a quicker lookup for data already received and reduces api calls for commonly used data. When setting the caching policy it applies to all queries that the client performs by default. Since the first run of this function grabbed stale data out of the cache, it would call the launch function again based on the shouldLaunchBrowserFromOpenBrowser always evaluating to true from the cache if all the criteria were good for launching initially.

Fortunately, there is a way to change the caching policy per query. By adding the requestPolicy with network-only it will ensure that the value for shouldLaunchBrowserFromOpenBrowser will be the most up-to-date and, subsequently, only call the function once.

launchIfBrowserSetInCli

This newly created function, like the resolver for shouldLaunchBrowserFromOpenBrowser, reuses functionality.

const launchIfBrowserSetInCli = async () => {
  const shouldLaunchBrowser = (await lsQuery).data.value?.localSettings?.preferences?.shouldLaunchBrowserFromOpenBrowser

  if (shouldLaunchBrowser) {
    await launch()
  }

  return
}

We grab the shouldLaunchBrowserFromOpenBrowser field. We then check to see if its truthy, or rather that it's true, and launch the browser. Either way, we return. Since the launch function already triggers component updates and UI updates, there is no need to create that logic.

onMounted

This is a lifecycle hook from Vue. The anonymous callback function will be executed when the component is mounted (rendered) to the screen.

onMounted(() => {
  launchIfBrowserSetInCli()
})

We simply call launchIfBrowserSetInCli when the component mounts and let the function do what is needs.

Putting it all together

When a user passes --browser chrome to the cypress cli (assuming chrome is installed), the user will be prompted to select an existing project.
Once the user chooses the project, another screen renders to allow the user to select the testing type (e2e or component).
On the final screen for browser selection during component mount, the lauchIfBrowserSetInCli function is executed based on the callback to onMounted.
A query to the localSettings object type is executed for the field shouldLaunchBrowserFromOpenBrowser.
- The resolver runs, and finds that the browser was passed to the cli, so it attempts to look it up.
- In this case we are successful and need to check if launchCount has been called.
- Since --browser was passed alone launchProject should not have been called, so the launchCount should evaluate to 0 and the resolver should return true
The query value is received and the if block is executed inside of launchIfBrowserSetInCli and the launch function is called.
The launch function updates the launching ref and executes a mutation to launchOpenProject to open the browser.
The browser is launched and the launching ref is flipped to false to show the updated opened browser state.

Since it is possible that a user can pass all flags and launch directly from the main page view, we can differentiate the calls to launchProject in ProjectActions.

The user passes all flags --project ./some/path --e2e --browser chrome
We have all the information we need to launch a project, so a mutation is sent to launch the project from the main view.
Once the mutation is executed, the loading state is stopped and we are brought to the browser selection screen.
Since the launchProject method has been called, launchCount has been incremented evaluating to 1. The query for shouldLaunchBrowserFromOpenBrowser returns false, skipping the if block in launchIfBrowserSetInCli and returning.
The UI for an already opened browser is shown.

Lets assume that a user passes only the browser flag but it is incorrect.

User passes --browser doesntExist to the cli.
After going through project and testing type selection the launchIfBrowserSetInCli function is called.
A query is made to the browser.
A "browser" was passed to the cli so we can move on and pass it to ensureAndGetByNameOrPath in the resolver.
Since the browser doesn't exist, an error is throw from ensureAndGetByNameOrPath and we return false.
The browser is not launched and a dismissible error is presented to the user letting them know that the browser wasn't found on the system.

During testing of this flow, I found that the launchProject method was being called when it shouldn't have been when reaching the browser selection screen in some instances. I inadvertently stumbled across a silent bug. There was a variable wasBrowserSetInCli which was a boolean that indicated if something was passed as a browser to the cli specifically. It did not perform checks on if it was a valid browser. So it would attempt to launch and fail. After some banging around and getting some much needed help from a maintainer, the issue was narrowed down to that variable. Swapping it out for the more precise shouldLaunchBrowserFromOpenBrowser field solved the issue.

Recap

Now users can pass a --browser flag alone with a name or path and select project and testing type options in the application before the browser is automatically launched. This helps to improve UX/DX by allowing a user to set up a script to run in a default browser and to be able to select between multiple projects and testing types in their local environment. This request has been ongoing since v10 and is now available in v13.4.0 and up!

This was a challenging PR to make. I ended up learning a lot. Before making this contribution, I knew nothing about GraphQL and the tooling around it. I knew of Typescript, but ended up taking a deeper dive since it was needed to navigate the codebase. I learned a little about Vue and the things I could and couldn't do. I was able to keep some code DRY as well. This was a pretty large and extensive code base and ended up reading a lot of it to fit the pieces together. In the end, this was a great opportunity to play with production code, give back to the development community, and to push the limits of what I know to add to the tool belt.

Thank you to the maintainers for their reviews and help along the way!