-
Notifications
You must be signed in to change notification settings - Fork 207
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
End runtime imports of types modules #6512
Comments
This may require moving back to dev / removing some packages that are currently |
Good to specify. I've added it to the body. |
just spent 20min puzzling over a case of this; had to phone a friend, so multiply some of that by 2 |
For prioritization: the ambient imports are adding ~60kb to each bundle of core proposals. Those cost money to put on chain. |
While working on Agoric/dapp-agoric-basics#21 , I learned that it's not necessary to import the ambient types into the executable module. A |
Reopening because #9076 only handled |
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? -->
refs: #6512 ## Description - further improves recent TypeScript best practices doc - turns the zoe/exported.js into a .d.ts so it can be used in triple-slash references - adopts that and stops the runtime imports of zoe/exported (progress on #6512) - remove the `maxNodeModuleJsDepth` now that the types resolve without - burns down imports so there are no inter-package runtime imports of typedefs. (leaving just a bit for #6512) I put commit checkpoints of type coverage to guard against any regression, though I took them out again when merging ### Security Considerations <!-- 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 <!-- 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 <!-- 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 <!-- 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 <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
What is the Problem Being Solved?
To use ambient types from one package in another, we've had to resort to runtime imports of empty modules (containing only types). For example,
agoric-sdk/packages/agoric-cli/src/init.js
Lines 4 to 7 in 8980a2d
Description of the Design
Eliminate runtime imports that are just for types.
Most of these cases will be by ensuring the necessary types are exported from the root of the package so that they can be imported where used in a concise way. E.g.
import('@endo/captp').TrapImpl
Remove or drop to
devDependencies
any packages that are currentlydependencies
in package.json just because of these imports.Security Considerations
--
Test Plan
Ensure that all the package
dependencies
are for modules needed at runtime.The text was updated successfully, but these errors were encountered: