feat: browser chunking

[Thunkar]

Further modularises noir-protocol-circuits-types, exposing a client/lazy API that allow browser bundles to not import every single JSON artifact at once, but rather pull them on demand. /server and /vks entrypoints are also provided to aid in startup CLI times, jest cache and general cleanup.

This is very important due to the sheer amount of different reset variants we currently have. However, a regular /client/bundle is still exposed in case dynamic imports are not supported in the target platform.

This takes our bundle sizes in the example vite box (with PXE in the browser and proving) from 50MB (30 compressed) to ~3MB before meaningful content is displayed. After that, bb.js is an additional 8-9 and each circuit hovers around 0.3-1, but only the ones used in the transactions are pulled when required.

Also removed the TestPrivateKernelProver, and replaced it by each of our prover implementations providing a cleaner simulation vs. witgen+proving interface. This way, the prover is now 100% a PXE plugin (which will allow us to even delegate proving!)

[spalladino]

Looks good! I left several comments but none of them are blockers. More in general, I got the same concern as with the previous PR for browser usage: it's really easy to screw this up by adding the wrong import in the wrong place. Should we tweak the vite or webpack box config so that it fails with an error if the bundle exceeds a certain size, so we don't inadvertently screw up the bundle again?

And a nit about naming: I'm not a fan of server/client/client-async. WDYT about server/client/browser? Though server/client can mean "the artifacts for the server/client" or "to be used in the server/client", which makes things confusing. Hmm...

[Thunkar]

Thanks for the comments @spalladino !

Had to revert to draft because I wanted to rework TestPrivateKernelProver too and completely forgot 😓

• Regarding moving stuff to base classes: totally agree and will try. But the tricky part is not polluting the imports, and it can get complicated quick with things sneaking in.
• Naming: Not 100% convinced about /browser since node can also load asynchronously (and it might make sense, eg: the CLI). Also not very fond of /client-async either.
• Tracking of bundle sizes: again 100% agreed, but wanted to wait until CI3 stabilization before adding a new task

[spalladino]

Tracking of bundle sizes: again 100% agreed, but wanted to wait until CI3 stabilization before adding a new task

I don't think it needs to be a new task. We should be able to configure webpack on aztec.js to error on bundle size exceeded using performance.hints and maxAssetSize (see here), and that build is already happening on CI.

[spalladino]

As for naming, I asked ChatGPT. I like the bundle vs lazy terminology:

Here are a few naming suggestions for your export entrypoints, keeping clarity and conventions in mind:

Option 1: Descriptive and Clear

"exports": { "full": "./full.js", "lazy": "./lazy.js" }
"exports": { "all": "./all.js", "async": "./async.js" }
"exports": { "eager": "./eager.js", "lazy": "./lazy.js" }

Option 2: Functional Names

"exports": { "importAll": "./import-all.js", "loadOnDemand": "./load-on-demand.js" }
"exports": { "preloaded": "./preloaded.js", "dynamic": "./dynamic.js" }
"exports": { "direct": "./direct.js", "asyncLoader": "./async-loader.js" }

Option 3: Conventional with API Terminology

"exports": { "static": "./static.js", "dynamic": "./dynamic.js" }
"exports": { "bundle": "./bundle.js", "loader": "./loader.js" }
"exports": { "synced": "./synced.js", "async": "./async.js" }

Option 4: Minimalist Style

"exports": { "sync": "./sync.js", "async": "./async.js" }
"exports": { "all": "./all.js", "lazy": "./lazy.js" }
"exports": { "core": "./core.js", "loader": "./loader.js" }

Key Considerations:

Eager/static/full: Names for the entrypoint that imports all artifacts directly.
Lazy/dynamic/async: Names for the entrypoint that asynchronously loads artifacts.
Consistency in naming (if you use verbs for one, like load, use them for both entrypoints).

[Thunkar]

@spalladino implemented your suggestions, finally went with /client/lazy and /client/bundle (with an additional /client for the common stuff)

[spalladino]

Awesome