-
Notifications
You must be signed in to change notification settings - Fork 212
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
more ts syntax #8335
more ts syntax #8335
Conversation
packages/vats/src/core/types.ts
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be types.d.ts
no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A '*.ts' file does seem to be unprecedented.
We have some *.d.ts
and some *.test-d.ts
(including one in vat-data/src
) but no *.ts
:
$ find . -name node_modules -prune -o -name moddable -prune -o \
-name '*.d.ts' -name '*.test-d.ts' -prune -o -prune -o \
-name '*.ts' -print
$
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, I have no problem with .ts
files for tests, and those do exist in the endo repo, I guess not (yet) in agoric-sdk.
And it's very much possible that a bare .ts
works in this case too, but I would find it too confusing and error prone as it's semantically different than types declarations only, which we want.
Small reviewing nit: it would have been nice to have a commit renaming / converting |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm hesitant to make a runtime change (however small) to the bootstrap vat in a PR about changing how types are written.
* Informs Zoe about an issuer and returns a promise for acknowledging | ||
* when the issuer is added and ready. | ||
*/ | ||
type SaveIssuer = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose it pre-dates this PR, but...
This type suggests there might be other implementations of SaveIssuer
. Seems like it should be inlined.
@@ -2,7 +2,9 @@ | |||
const start = zcf => { | |||
/** @type {OfferHandler} */ | |||
const handler = (_seat, offerArgs) => { | |||
// @ts-expect-error xxx HandleOffer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit reluctant to speak for @Chris-Hibbert and @erights re maintaining zoe package types in typescript rather than JSDoc, but I suppose this sort of thing shows that maintenance was suffering anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
packages/vats/src/core/types.js
Outdated
*/ | ||
|
||
/** @template T @typedef {{vatPowers: { D: DProxy }, devices: T}} BootDevices<T> */ | ||
// Dummy file for .ts twin to declare ambients |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ambient ts is an interesting approach...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just questions. I'm no authority.
packages/vats/src/core/types.ts
Outdated
> | ||
>; | ||
walletFactory: Promise< | ||
Installation<import('@agoric/smart-wallet/src/walletFactory.js').start> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a typo, or is typeof
required here? The cases above needed it.
Installation<import('@agoric/smart-wallet/src/walletFactory.js').start> | |
Installation<typeof import('@agoric/smart-wallet/src/walletFactory.js').start> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes. .ts syntax is less forgiving that .js/JSDoc syntax in this regard
packages/vats/src/core/types.ts
Outdated
type AgoricNamesVat = ERef< | ||
ReturnType<typeof import('../vat-agoricNames').buildRootObject> | ||
>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does typescript allow one to make shorthand for the oft-repeated ERef<ReturnType<typeof importedThing.buildRootObject>>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good idea! We can have a utility type for the root object of a vat.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried DRYing out the buildRootObject
reference but I haven't found a way to get the module import to be a generic type for s helper. It might require a module import, which would break this being an ambient.
We could DRY the ERef<ReturnType<
but it wouldn't save a lot of characters unless we also do a helper like ContractInstallationPromises
(which I just added). I expect eventually we'll want one for devices to be keys in a namespace instead of named by concatenation
packages/vats/tsconfig.json
Outdated
@@ -9,6 +9,7 @@ | |||
"*.js", | |||
"scripts/**/*.js", | |||
"src/**/*.js", | |||
"src/**/*.ts", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be
"src/**/*.ts", | |
"src/**/*.d.ts", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's here works, but would allow src
to have runtime .ts
files so I think your suggestion is worth including. I'll do it in a cleanup push
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I trust you'll also reach consensus with @mhofman and co.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I think my confusion came from the fact that some bundlers or other pieces of tooling would fail if importing a js file that isn't a module by heuristics (aka doesn't have any import or export statement), but apparently that's not a problem since both before and after the type.js file doesn't have those statements, and it is runtime imported. So all clear on my end, sorry for the confusion.
cd7c7ee
to
365be75
Compare
Your concern was well-placed! The typescript-eslint plugin was failing to load the empty .js files. I have included this work-around: 365be75 |
6aea57b
to
c6c5acb
Compare
c6c5acb
to
7edc3e9
Compare
The eslintconfig change wasn't reviewed. I merged to reduce the risk of merge conflicts and ease building atop it. But if anyone has a better solution or request I'm happy to hear them and will follow up. |
Description
Motivation was to be able to document the promises in BootstrapSpace. That required adopting .ts syntax. I experimented with some more conversions.
Security Considerations
none
Scaling Considerations
n/a
Documentation Considerations
We should convert the whole codebase to this style for consistency,
-#8342
Testing Considerations
CI suffices
Upgrade Considerations
n/a