feat(xsnap): deep stacks work with updated moddable error stacks

[dckc]

I usually add a test... how important is that? What would / should it look like?

[erights]

I usually add a test... how important is that? What would / should it look like?

For a test that runs after lockdown is called, how about something like:

test('something', t => {
  const foo = () => {
    const err = Error('msg');
    t.assert(!('stack' in err));
    const msg = getStack(err);
    t.is(typeof msg, 'string');
    t.assert(msg.length >= 1);
});

[dckc]

I get ReferenceError: get getStack: undefined variable. xsnap only uses the lockdown shim, not all of SES (recall we avoid babel). Does the lockdown shim provide getStack as a global?

[erights]

I get ReferenceError: get getStack: undefined variable. xsnap only uses the lockdown shim, not all of SES (recall we avoid babel). Does the lockdown shim provide getStack as a global?

Ah sorry. getStackString.

[kriskowal]

This is unspeakably exciting.

[kriskowal]

I worry that this obscures the provenance of the file, but I assume this is motivated by IDE auto-complete to open a file, which is worthy. Maybe we could stutter dist/dist-bootstrap.js? Whatever we do, it should be a rule we follow elsewhere.

[dckc]

The rule this change is designed to follow is:

# bundles
bundle-*.js

https://github.com/Agoric/agoric-sdk/blob/master/.gitignore#L56-L57

I'm not sure what you mean by "this" in "I worry that this obscures..." A change from bootstrap to bundle-sys-boot obscures?

Maybe I should get rid of this bundle in favor of a t.before function. It was only used in tests, originally. It's now used in ava-xs, but ava-xs also uses bundleSource on test scripts, so it might as well bundle this at runtime too.

[kriskowal]

I’d be down for, as a rule, naming bundle-x.js for every input x.js. That would imply, for example, dist/bundle-ses.umd.js and dist/bundle-lockdown.umd.js elsewhere, and bundle-bootstrap.umd.js here.

[kriskowal]

Or rather, it would be. I think we depend too heavily on the exact names in ses/dist. In some cases the dist files are part of the public API.

[dckc]

it seems like the name of this file is independent of deep stacks... but I guess I raised the issue when I renamed it in this PR.

Currently, ava-xs is the only consumer. And having it in the xsnap package is increasingly awkward. But I expect xsnap to move to SES-shim (or endo) in due course, so I'm inclined to not bother with this just now. I suppose I owe an issue about it or something...