-
Notifications
You must be signed in to change notification settings - Fork 221
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
chore(swingset-liveslots): export TypeScript definitions #10869
chore(swingset-liveslots): export TypeScript definitions #10869
Conversation
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 don't understand the motivation for introducing a "types"
field in package.json
(and the manual ts-types.d.ts
file. Our types-index
approach should work just as well (if it doesn't, I'd like to understand why)
Adding @turadg as he has practice with similar changes.
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.
Any reason to change away from our types-index
approach? We tend to avoid adding a types
field to the package.json
as it's often unnecessary if sibling .d.ts
files are generated.
Some of this is described in https://github.com/Agoric/agoric-sdk/blob/master/docs/typescript.md
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.
One issue is that typescript expects a definition of the index
file when we import it, else it can't find the types even with the types-index.js
approach. This is solved with the pre/postpack commands. Another issue is that we need to export types that aren't part of the runtime hence the types-index
approach, which already handled that.
I was trying to avoid making an exception at the postpack
which deletes all the definitions (along with the hardcoded one types-index.d.js
) hence the type
key. My ts-types.ts
is not referenced on runtime somewhere. types-index.js
was renamed to ts-types.ts
but I can revert that of course. It seemed to me it's not the index
since index.d.ts
is the index now.
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.
Thanks for explaining. To help keep the codebase manageable we try to be consistent across packages. For this PR please follow the guidelines in https://github.com/Agoric/agoric-sdk/blob/master/docs/typescript.md and if you think they should let's have another PR which updates that guidance and implements the new practice across all the packages.
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.
5b4d8c8
to
0211466
Compare
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.
Thanks for the contribution!
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.
Seems fine with a minor nit.
0211466
to
8157b30
Compare
This failure is real:
It wasn't detected until integration testing that doesn't run on PR pushes by default (until merge or a It appears the d.ts broke the ambients. There might be a lot of changes required to get this passing. (Incidentally this is an issue this PR advances so I've linked it in the description.) I can help but probably not until next week. |
refs: #6343
Description
Properly expose TypeScript definitions from
@agoric/swingset-liveslots
package by adding TypeScript build steps inpackage.json
which generate the definitions.Security Considerations
No security impact - only affects TypeScript type definitions which are stripped at compile time.
Scaling Considerations
No scaling impact - changes only affect development-time TypeScript support.
Documentation Considerations
No documentation updates needed - this is a developer-facing change for TypeScript users.
Testing Considerations
Existing type coverage tests continue to pass. No additional testing needed as this only affects type definition exposure.
Upgrade Considerations
No upgrade impact - purely development-time TypeScript support changes.