-
-
Notifications
You must be signed in to change notification settings - Fork 6
feat: add trust level computation core module #138
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
base: main
Are you sure you want to change the base?
Conversation
commit: |
|
Looks good! |
| * Core modules containing pure, reusable logic that can be imported | ||
| * by external tools like the e18e GitHub Action. | ||
| */ | ||
| export * from './trust.js'; |
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 wonder if we should drop this barrel file as we export them in the root anyway
instead of this re-exporting everything, and the root re-exporting them again. we can just put this in the root
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.
the reasoning behind having this barrel file was the aim of expanding core modules, if you think this won't be the case, then yes this would be unnecessary.
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 think it will be the case. But things like the GitHub action will import them from the root. So we will just be exporting them twice internally if we keep this as it is.
Internally I think we should be avoiding barrel files. The only place we should really have one is the root entry point.
So everywhere that imports these should get them directly or from the root
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.
sounds good, will drop this as well
| * Metadata about an npm package version, containing provenance information. | ||
| * This is a subset of the full npm registry metadata. | ||
| */ | ||
| export interface PackageProvenanceMetadata { |
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.
presumably there's a util which fetches the metadata and uses this type too?
do we want to include that in here? where does the action have it today?
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 can't recall why i added that type tbh, i think i wanted to implement the type cause i was thinking of adding an utility in core. but it has passed a month already since i worked on this.
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.
its basically the response type of the npm API by the looks of it
so we should either drop it for now, or introduce the helper function that hits the npm api and uses it
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'll drop this for now so we can discuss and refine the details together during Friday's meeting.
adds a new
core/trustmodule with pure functions for computing npm package trust levels based on provenance attestations. This is the foundation for sharing logic between the CLI and the GitHub Action.