-
Notifications
You must be signed in to change notification settings - Fork 2
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
Browser build and package split #34
Conversation
7732d2a
to
84e1a10
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.
Nice work! Just a few "administrative" comments.
package.json
Outdated
"typedoc": "^0.22.17", | ||
"typescript": "^4.7.4", | ||
"typescript-eslint-language-service": "^5.0.0" | ||
"hpke": "file:hpke-0.2.0.tgz" |
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.
As you suggested in offline discussion, let's cut a release of hpke-dispatch
before merging to avoid the need to vendor the HPKE library.
packages/dap/src/nonce.ts
Outdated
@@ -0,0 +1,25 @@ | |||
import { Buffer } from "buffer"; |
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.
nit: I think this file ended up having its contents copied instead of being git mv
'ed somehow -- at least, GitHub doesn't seem to understand it was moved from its previous location.
@@ -0,0 +1,1444 @@ | |||
/// source: https://github.com/GuildOfWeavers/galois |
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.
We'll probably want to vendor new versions of this library eventually; IMO it'd be very helpful to include some instructions on how to update this library. (i.e. grab the repo, copy these parts over, make these manual changes, ...)
An automated script to "regenerate" the vendored library would be ideal, but depending on how complex the vendoring process is, may be more work than is warranted. And it'd be easy for updates to the galois library to break an automated script.
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 we should consider this a hard fork, and plan to independently maintain all of the code in perpetuity. Part of the motivation behind this change was realizing we were going to end up doing that either way, since upstream seems mostly unmaintained. Part of that should probably be removing any code we don't use, and making sure we have better test coverage than in this PR
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.
Thinking about this some more, I think you're right that this is the best option. Needing to maintain a finite-field library is not ideal, but given that upstream is unmaintained, we might not have much choice.
Also, it looks like there's a non-flaky test failure. IIUC, it's because the new field library doesn't have sufficient coverage. Since we are vendoring this library, perhaps we can either reduce the required coverage or exclude the library from coverage requirements entirely? |
b6d3324
to
cc52e12
Compare
Pull Request Test Coverage Report for Build 3138461862Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
This is pending divviup/hpke-dispatch#12 |
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.
LGTM modulo waiting for an hpke-dispatch release.
7fcdc31
to
e7a2e19
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.
We've got three different standalone files in the scripts directory -- are those okay where they are, or would you recommend giving them a separate package? (They also need some export/import work to fix them, but that can wait)
There are still three files underneath src
. I think those should go away, with the possible exception of src/index.ts
if we need to re-export items from the root package.
Nice work, I'm excited to get this cooking!
"typedoc": "^0.23.10", | ||
"typescript": "^4.7.4", | ||
"typescript-eslint-language-service": "^5.0.0" | ||
"@parcel/packager-ts": "^2.7.0", |
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.
We should add parcel
as a top-level devDependency as well. I tried running npm i && npm run build
, and it failed on the parcel build
command prior to installing it.
packages/common/package.json
Outdated
"format": "prettier -w src", | ||
"test:coverage": "nyc --cwd=../.. --no-clean --reporter=lcov --reporter=text --reporter=json npm test", | ||
"ci": "npm run lint && npm run test:coverage", | ||
"benchmark": "ts-node scripts/benchmarks.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.
nit: this command is defined on several packages, but we only have the one benchmark script hanging off of the top-level package.
"rootDir": "src", | ||
"outDir": "dist" | ||
}, | ||
"include": ["src"] |
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.
nit: some directories have "include": ["src"]
, while others have "include": ["./src/*.ts"]
. Should these all use the *.ts glob version instead?
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 this is because some have subdirectories within src, so "src" is the more general variant
0fca2d3
to
4125471
Compare
The biggest change in this PR is switching away from using the galois library and instead just vendoring the parts of galois that we need. It turned out that we did not actually use the assemblyscript because none of our moduli were in the range that their optimizations applied to, so trying to figure out how to upgrade and maintain that part of the library was entirely unnecessary. Instead, we vendor just the TS implementation, which is what we were executing anyway.
This PR currently uses an unpublished version of the HPKE library; PRing and publishing that will allow us to depend on it and remove the vendored tgz.