refactor: start replacing Far with makeExo #9046
Conversation
| @@ -8,7 +8,7 @@ harden(defaultLabelToKeys); | |||
| /** | |||
| * @param {string} debugName Only used internally for diagnostics, not available to user code | |||
| * @param {import('./types.js').Stores} stores | |||
| * @param {import('@agoric/swingset-liveslots').MapStore<string, any>} [backingStore] | |||
| * @param {MapStore<string, any>} [backingStore] | |||
There was a problem hiding this comment.
This is a drive-by. The import from swingsets-liveslots is a layering violation that was not caught by our normal circularity checking, because the typing dependency apparently need not be represented by a package.json "dependency":. In any case, trying to import MapStore as import('@agoric/store').MapStore did not work, but the type MapStore seems to be in scope correctly anyway.
There was a problem hiding this comment.
Spoke too soon. Using a plain MapStore, yarn lint in @agoric/store works fine, but yarn lint in @agoric/vow` gives
../base-zone/src/make-once.js:11:12 - error TS2304: Cannot find name 'MapStore'.
11 * @param {MapStore<string, any>} [backingStore]
@michaelfig @turadg , help (not urgent). Is there a coherent explanation anywhere of these type scoping rules? My attempt to absorb them by example has only dug me into an ever deeper hole of confusion.
There was a problem hiding this comment.
Check your package's tsconfig.json and note under .compilerOptions.maxNodeModuleJsDepth there is an integer that says how deep Typescript should traverse into other modules for ambient types. If you increase that number, then it will work again.
That said, once we actually create the @endo versions of these packages, we should ensure they no longer rely on ambient types, and instead use explicit exports and imports. Turadg knows more about how this migration will happen, and it may be gated on (future) Typescript features to minimize the blast radius.
There was a problem hiding this comment.
I'd love to do that. @turadg , is there an explanation of what the type scoping rules are once we've completely weaned ourselves of ambient types? Are we in fact waiting on future TS features before we make this conversion? How much of this would be done by your postponed Passable-typing endo PR? Does the new jsdoc support for better type import mean we will be able to stop repeating import('...'). at every use occurrence?
There was a problem hiding this comment.
is there an explanation of what the type scoping rules are once we've completely weaned ourselves of ambient types?
Types will have to be explicitly imported into the module.
Are we in fact waiting on future TS features before we make this conversion?
There are no blockers. Mostly it hasn't been prioritized.
Does the new jsdoc support for better type import mean we will be able to stop repeating import('...'). at every use occurrence?
Yes, exactly. So waiting for TS 5.5 (https://github.com/microsoft/TypeScript/issues/57475) will reduce the downstream impact.
How much of this would be done by your postponed Passable-typing endo PR?
Totally orthogonal.
|
@erights want to try doing it in an example dapp first? |
Yes, good idea. |
closes: #XXXX
refs: endojs/endo#2118
Description
See endojs/endo#2118 for the description. Pretty much all said there wrt endo applies here wrt agoric-sdk.
However, this first commit is only of the automated part. Due to the greater surface area, none of the manual steps are started, and so massive CI failures are expected.
Security Considerations
Scaling Considerations
Documentation Considerations
Testing Considerations
Upgrade Considerations