malformed bundle is difficult to diagnose

[cowboyd]

When encountering #800, this catestrophic misconfiguration only reported the realtively innocuous error message in the server output:

[manifest builder] build error:
Cannot read property 'map' of undefined

We should clearly indicate that bigtest could not process the bundle probably due to an internal error and that we should report the issue. It might even be panic-worthy.

[dagda1]

I personally think insisting on a default export is problematic and I think we should work with named exports. Default exports in typescript are not the norm which in someway has something to do with them initially being difficult to implement before esModuleInterop was added.

We don't appear to have any runtime checks and I don't think a generic error message is going to wash here.

I created #530 which was refused and I do get the reasons but a generic error message with no indication that it is the default export will prove difficult to diagnose.

[cowboyd]

I agree with you that in most cases a default export is not good, which we generally eschew it. However, in this case, not using a default export only sweeps the problem under the rug. We would need a "magic" named export that would have to be there, otherwise we couldn't discover and link the test. E.g. export const theTest = test('My Test'); and then our bundler would have to look for an export called theTest instead of default. Same problem, different name.

All that aside, in this case, the problem wasn't the default export, right? The test did have one, but it was the typescript config was missing and so the default export wasn't being bundled. I field the issue so that we could have a placeholder to remind us that sometimes things will be borked, and we want to give as much of a diagnosis as possible.

[dagda1]

We would need a "magic" named export

I was forgetting about the reason why. That is tricky and would possibly need some AST trickery to cure it. The default export is good enough for now but we need really good validation that points to there not being a default export.

All that aside, in this case, the problem wasn't the default export, right? The test did have one, but it was the typescript config was missing and so the default export wasn't being bundled. I field the issue so that we could have a placeholder to remind us that sometimes things will be borked, and we want to give as much of a diagnosis as possible.

Oh maybe there is more than one case.

This fails with the .map error also

import { test } from '@bigtest/suite';

export const t = test("No default export");

That is why I am being pedantic about this, if I get the big long error message that points to the github issue then I probably will not get that this is a basic validation error message.

I was thinking of adding something like this to validate-test:

  if ( [test?.assertions, test?.children].some(c => {
    return Array.isArray(c) === false;
  })) {
    throw new TestValidationError(`
Invalid Test: Test contains no assertions or children.
Does the test file ${test.path} contain a default export.
Test: ${[test.description].join(' → ')}`, test.path);
  }

The code in validate-test expects there to be assertions and children in order to call map on them.

[dagda1]

this will also obviously fail as there are no assertions and children to map over:

module.exports = {
  description: 'no assertions or children';
}

[cowboyd]

We should probably validate that there are both children, and assertions since they are part of the Test interface, and their absence would indicate that something is malformed.