refactor: modernize @endo/errors @agoric/store imports #8781
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.
closes: #XXXX
refs: #8771
Description
Now that a recent endo is released and agoric-sdk has been upgraded to depend on it, we can finally get to a lot of agoric-sdk technical-debt cleanups that we've postponed. The cleanups in this PR include:
assert
from the global or @agoric/assert package to its successor @endo/errors.There's one trivial semantic change in switching many asserts to @endo/errors. Unlike the global
assert
or theassert
exported by@agoric/assert
, theassert
object as exported by@endo/errors
does not have non-asserting methods likenote
(akaerrorNote
) orerror
(akamakeError
). Thus, when these were called as methods onassert
, I had to import the functions directly, and then change the code to call the function, rather than making a method call. Other than that, this PR should have very little aside from changing imports and a few reexports + thepackage.json
changes needed to depend on those endo packages.Extracted from #8771 per #8771 (comment) but made into a separate PR so it can be merged or not on its own.
Also includes @turadg 's fix to the casting maxNodeModuleJsDepth from #8771
Security Considerations
none
Scaling Considerations
none
Documentation Considerations
none
Testing Considerations
none
Upgrade Considerations
@ivanlei , I added you for feedback on when it would not be too disruptive to merge this. That's another reason to separate it into a PR distinct from the remaining changes in #8771 . By minimizing the non-import-export code changes, it shouldn't much hurt our ability to cherry pick.