refactor: use @endo/errors when acyclic #2324
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
erights
commented
Jun 16, 2024
kriskowal
approved these changes
Jun 17, 2024
erights
added a commit
that referenced
this pull request
Jun 17, 2024
Closes: #XXXX Refs: Agoric/agoric-sdk#9515 Agoric/agoric-sdk#9514 ## Description Addresses Agoric/agoric-sdk#9515 as applied to endo, by doing for endo what Agoric/agoric-sdk#9514 does for agoric-sdk To address Agoric/agoric-sdk#5672 for endo , we should change all applicable uses of `assert` to obtain `assert` by importing it from the `@endo/errors` package. However, attempts to do so ran into the symptoms reported at Agoric/agoric-sdk#9515 for the reasons reported there -- accidentally using the imported `assert` as the endowment for the global `assert` of new Compartments. This PR prepares the ground for these fixes to Agoric/agoric-sdk#5672 for endo by unambiguously endowing with the original unstructured `globalThis.assert`, which will remain the correct endowment even when other uses of `assert` have migrated to the one imported from `@endo/errors`. By itself, this PR, preceding those fixes to Agoric/agoric-sdk#5672 for endo , is not actually fixing a bug in the sense of a behavioral change. Reviewers, let me know if you think this PR should be labeled a "refactor" because of this. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations anyone gathering endowments for a new compartment should be aware of this issue, and be sure to use `globalThis.assert` as the `assert` endowment. Fortunately, this will only be of concern to advanced developers. ### Testing Considerations Since this PR doesn't actually cause any behavioral change, it cannot be tested in place. Rather, its test will be whether #2324 still passes CI once rebased on this PR. ***Update***: #2324 is now passing CI well enough to consider this PR (#2323) to be adequately tested. ### Compatibility Considerations The point. This PR itself only prepares the ground for the equivalent of Agoric/agoric-sdk#9513 for endo. By itself it has no other effect, and so no other compat issues. ### Upgrade Considerations none
erights
force-pushed
the
markm-assert-from-endo-errors
branch
from
358854c
to
64d815e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Staged on #2323
Closes: #XXXX
Refs: Agoric/agoric-sdk#5672 Agoric/agoric-sdk#9513
Description
Does for endo what Agoric/agoric-sdk#9513 does for agoric-sdk --- importing
assertfrom @endo/errors --- when it can do so without causing dependency cycles. For the remaining packages that would cause dependency cycles, just move them towards more modern assert conventions while still using the unstructured globalassertSecurity Considerations
none
Scaling Considerations
none
Documentation Considerations
We should document
assertonly as imported from @endo/errors, since our users will not generally contribute code within endo's internal dependency cycles.Testing Considerations
The CI run on this PR also serves to test #2323, since that one, by itself, does not cause a behavioral change. It's purpose is to enable this PR not to hit the problem described at Agoric/agoric-sdk#9515
Compatibility Considerations
none
Upgrade Considerations
none