Skip to content
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

Merged
merged 1 commit into from
Sep 30, 2022
Merged

Conversation

jbr
Copy link
Contributor

@jbr jbr commented May 28, 2022

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.

@jbr jbr marked this pull request as ready for review July 7, 2022 16:49
@jbr jbr force-pushed the browser-build-and-package-split branch from 7732d2a to 84e1a10 Compare July 7, 2022 17:14
@branlwyd branlwyd self-requested a review July 8, 2022 21:39
Copy link
Contributor

@branlwyd branlwyd left a 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"
Copy link
Contributor

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.

@@ -0,0 +1,25 @@
import { Buffer } from "buffer";
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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.

@branlwyd
Copy link
Contributor

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?

@jbr jbr force-pushed the browser-build-and-package-split branch 2 times, most recently from b6d3324 to cc52e12 Compare July 12, 2022 20:23
@coveralls
Copy link

coveralls commented Jul 12, 2022

Pull Request Test Coverage Report for Build 3138461862

Warning: 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

  • 414 of 438 (94.52%) changed or added relevant lines in 28 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-1.7%) to 91.609%

Changes Missing Coverage Covered Lines Changed/Added Lines %
packages/vdaf/src/index.ts 8 9 88.89%
packages/common/src/index.ts 16 21 76.19%
packages/field/src/PrimeField.ts 227 245 92.65%
Totals Coverage Status
Change from base Build 3047637308: -1.7%
Covered Lines: 978
Relevant Lines: 1038

💛 - Coveralls

@jbr jbr requested a review from branlwyd July 18, 2022 18:23
@jbr
Copy link
Contributor Author

jbr commented Jul 18, 2022

This is pending divviup/hpke-dispatch#12

Copy link
Contributor

@branlwyd branlwyd left a 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.

Copy link
Collaborator

@divergentdave divergentdave left a 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!

packages/vdaf/src/index.ts Outdated Show resolved Hide resolved
"typedoc": "^0.23.10",
"typescript": "^4.7.4",
"typescript-eslint-language-service": "^5.0.0"
"@parcel/packager-ts": "^2.7.0",
Copy link
Collaborator

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.

"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"
Copy link
Collaborator

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"]
Copy link
Collaborator

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?

Copy link
Contributor Author

@jbr jbr Sep 27, 2022

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

@jbr jbr force-pushed the browser-build-and-package-split branch from 0fca2d3 to 4125471 Compare September 30, 2022 19:13
@jbr jbr merged commit 6d332aa into main Sep 30, 2022
@jbr jbr deleted the browser-build-and-package-split branch September 30, 2022 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants