🦋 Changeset detected

Latest commit: 6e9ec72

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

The preview packages of this pull request have been published.
Click on the following packages for instructions on how to install them:

$ npm install @bigtest/agent@raise-bundler-errors-to-the-top

{
  "@bigtest/agent": "raise-bundler-errors-to-the-top"
}

$ npm install bigtest@raise-bundler-errors-to-the-top

{
  "bigtest": "raise-bundler-errors-to-the-top"
}

$ npm install @bigtest/interactor@raise-bundler-errors-to-the-top

{
  "@bigtest/interactor": "raise-bundler-errors-to-the-top"
}

$ npm install @bigtest/server@raise-bundler-errors-to-the-top

{
  "@bigtest/server": "raise-bundler-errors-to-the-top"
}

$ npm install @bigtest/suite@raise-bundler-errors-to-the-top

{
  "@bigtest/suite": "raise-bundler-errors-to-the-top"
}

Generated by 🚫 dangerJS against 6e9ec72

Do we want to kill the CLI if there is a bundler error? or is this just in the event that we can't actually link and load the bundle. It seems to me there are two things:

1. The CI command should definitely fail
2. the server should continue running, but it might make sense to crash if a certain class of errors (what amounts to linkage errors) percolate upwards.

Good point, I think we have different types of exceptions.

I think we can say that a test that looks like this:

{
  test: {
    t: TestBuilder {
      description: 'No default export',
      steps: [],
      assertions: [],
      children: [],
      state: 'step'
    },
    fileName: 'manifest-54f435368391c9a6f8b73ea545058998181e4f5f0c28e868b684878125ca0ab8.js'
  }
}

A test that has no default export, i.e. none of the keys we expect (description, steps) etc. then we don't crash the CI.

For unhandled or unexpected exceptions, we crash the CI.

How do we differentiate the two?

How do we differentiate the two?

By the type of exception. As we know, there are no multiple catch blocks in javascript so we could use a type guard or something like:

const isUnandledException(err: any) => /// using some tag on our custom Errors 

and then

        } catch(error) {
          console.debug("[manifest builder] error loading manifest");
          bundlerSlice.update(() => ({ type: 'ERRORED', error }));
          
          if (isUnandledException (error)) {
            return;
         }
          throw error;

closed in favour of #809