Four problems when running "current" agoric-sdk on "current" endo

[erights]

I use #7937 to detect when there would be a problem if "current" agoric-sdk were upgraded to depend on "current" endo. My latest CI run just now https://github.com/Agoric/agoric-sdk/actions/runs/6514769656/job/17696503348?pr=7937 indicates four failures under CI. Two of these are lint failures and may have a common underlying cause. The other two are dynamic failures I have no diagnosis for, but they seem like distinct problems.

[erights]

Attn @kriskowal @michaelfig

[michaelfig]

I reran #7937 just now. Here is the latest CI: https://github.com/Agoric/agoric-sdk/pull/7937/checks

[kriskowal]

We should probably address the Babel concern by narrowing the semver range to exclude the incompatible versions (assuming all future versions are incompatible until they release the fix. They’ve landed babel/babel#16025 but we should verify before relaxing.)

[michaelfig]

We should probably address the Babel concern by narrowing the semver range to exclude the incompatible versions (assuming all future versions are incompatible until they release the fix.

I'd like to do something like this, but I'm overwhelmed by the number of babel dependencies in the agoric-sdk when resolving the new @endo/evasive-transform. Do I just need to hack up that package (I'm thinking patch-package in agoric-sdk) so that it doesn't introduce anything new, or what do you suggest concretely as a strategy?

[kriskowal]

@michaelfig I got this far yesterday endojs/endo#1842

@mhofman saw evidence that there was a release with a fix. I’ve been unable to verify the fix. I’m seeing the property override with all the latest versions from babel, even if I retract our fork of babel/generator and nuke the stale integration test which entrains older versions.

So I’m back to assuming we need to narrow the version range again. That’d be saying ^7 && <7.x for the versions that introduced the override mistake. (I have not yet narrowed that down either.) I’m not confident of success, but I’m running low on ideas. On the plus side, the set-versions.sh script can be hacked to punch shallow dependencies of all the babel packages throughout our workspaces. I’m not confident that will cover transitive dependencies that depend on wider ranges of Babel.

For the broader problem, we may need to begin a document with recommended resolutions for dapps, at least until this conflict with Babel settles.

[mhofman]

I am confused why the newer version wouldn't be sufficient. Have you been able to capture an error stack where the override mistake triggers?

[mhofman]

I previously identified the version in which the override mistake trigger was introduced. Let me dig that out.

Edit: I think the trigger (different import statement) got introduced in babel/babel@e43d8e7 which seem to have first been released in v7.22.13

[kriskowal]

Endo and Agoric are in sync today.