Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ta/topological prepack #9300

Draft
wants to merge 12 commits into
base: master
Choose a base branch
from
Draft

ta/topological prepack #9300

wants to merge 12 commits into from

Conversation

turadg
Copy link
Member

@turadg turadg commented Apr 28, 2024

  • build: update replace-packages for npm build
  • feat(types): explicit exports from notifier package
  • fix(types): include VatAdminSvc in ambient exports
  • chore(type): work around ' Bundle' type bug*
  • feat(types): explicit exports from zoe
  • feat(types): AdminFacet generic
  • WIP
  • WIP2
  • WIP3
  • fixup! feat(types): explicit exports from zoe
  • WIP
  • chore(types): @import

closes: #XXXX
refs: #XXXX

Description

The packages currently build in alphabetical order. They should be able to build in topological order, but the ambient types dependency spaghetti prevents that.

This PR is a WIP to solve it, but making all packages export types that others can import

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

Upgrade Considerations

Copy link

cloudflare-pages bot commented Apr 28, 2024

Deploying agoric-sdk with  Cloudflare Pages  Cloudflare Pages

Latest commit: 32c32ca
Status:🚫  Build failed.

View logs

mergify bot added a commit that referenced this pull request May 1, 2024
refs: #6512

## Description

Progress on #6512, spawned from #9300.

This gives the @agoric/notifier package explicit exports.

Many downstream packages were relying on @agoric/notifier ambients for
types from @agoric/internal or Endo, so this also adds an `exported.js`
to @agoric/internal to provide those. (E.g. `ERef`).

### Security Considerations
none, types
<!-- Does this change introduce new assumptions or dependencies that, if
violated, could introduce security vulnerabilities? How does this PR
change the boundaries between mutually-suspicious components? What new
authorities are introduced by this change, perhaps by new API calls?
-->

### Scaling Considerations
none, types
<!-- Does this change require or encourage significant increase in
consumption of CPU cycles, RAM, on-chain storage, message exchanges, or
other scarce resources? If so, can that be prevented or mitigated? -->

### Documentation Considerations

might improve API docs of Notifier package
<!-- Give our docs folks some hints about what needs to be described to
downstream users.

Backwards compatibility: what happens to existing data or deployments
when this code is shipped? Do we need to instruct users to do something
to upgrade their saved data? If there is no upgrade path possible, how
bad will that be for users?

-->

### Testing Considerations
CI
<!-- Every PR should of course come with tests of its own functionality.
What additional tests are still needed beyond those unit tests? How does
this affect CI, other test automation, or the testnet?
-->

### Upgrade Considerations
none, types
<!-- What aspects of this PR are relevant to upgrading live production
systems, and how should they be addressed? -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant