@o1js/testing

[boray]

This pull request introduces a new package @o1js/testing and includes several changes to support this addition. The changes involve setting up the package structure, configuration files, and exporting necessary utilities.

New Package Setup:

• src/testing/package.json: Created a new package.json file to define the @o1js/testing package, including scripts for building and testing, and specifying dependencies.
• src/testing/CHANGELOG.md: Added a changelog file to document notable changes in the project, adhering to the Keep a Changelog format and Semantic Versioning.

Configuration and Build Tools:

• src/testing/jest.config.js: Added a Jest configuration file to set up the testing environment for the package, including presets and transform ignore patterns.
• tsconfig.testing.json: Created a TypeScript configuration file specifically for the testing package to manage compilation settings and include/exclude patterns.
• src/testing/copy-bindings.js: Added a script to copy bindings from the build directory to the distribution directory.

Exporting Utilities:

• src/testing/index.ts: Created an index file to export all testing utilities from the src/testing.js file.
• src/testing/src/testing.ts: Imported and re-exported various utilities from equivalent.js, property.js, and constraint-system.js to make them available as part of the testing package.
• src/lib/testing/equivalent.ts: Updated the export statement to include AnyTupleFunction.

TODO

This PR will have couple of follow-up tasks and PR's for:

• Creating namespaces in src/lib/testing for better organization of tools
• Adding TSDoc style comments to src/lib/testing
• Discuss creating a packages directory for o1js,mina-signer and @o1js/testing internally.

[boray]

Overall this looks reasonable! Can I try using it locally with npm link? I tried from the src/lib/testing folder and it didn't work.

I used yalc to test the package so far. It should work with npm link too. Can you explain how it failed?

[45930]

For example, the react testing library doesn’t have a code block to install react. It just mentions that it’s a peer dependency. https://github.com/testing-library/react-testing-library I don’t think it’s a big deal either way. But it just seems like anyone installing this package will know how to install o1js too.

On Thu, Apr 3, 2025 at 4:50 PM, Boray Saygılıer @.> wrote: Overall this looks reasonable! Can I try using it locally with npm link? I tried from the src/lib/testing folder and it didn't work. I used yalc to test the package so far. It should work with npm link too. Can you explain how it failed?— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.>
boray left a comment (o1-labs/o1js#2093) Overall this looks reasonable! Can I try using it locally with npm link? I tried from the src/lib/testing folder and it didn't work. I used yalc to test the package so far. It should work with npm link too. Can you explain how it failed? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[boray]

I don’t think it’s a big deal either way. But it just seems like anyone installing this package will know how to install o1js too.

oops, I missed it's for o1js not @o1js/testing. Indeed, it's an overkill. I changed this while ago but not commited. It just has a note about peer dependency. The current version of the readme is incomplete. I'll be pushing updates tomorrow.

[Trivo25]

How do you want to release this to npm, if at all?

[boray]

How do you want to release this to npm, if at all?

We can release as a scoped package under o1js on demand similar to mina-signer.

[Trivo25]

How do you want to release this to npm, if at all?

We can release as a scoped package under o1js on demand similar to mina-signer.

Right, but manually or through CI?

[boray]

How do you want to release this to npm, if at all?

We can release as a scoped package under o1js on demand similar to mina-signer.

Right, but manually or through CI?

Manually, I don't think we should release this package in a strict cadence.

[Trivo25]

How do you want to release this to npm, if at all?

We can release as a scoped package under o1js on demand similar to mina-signer.

Right, but manually or through CI?

Manually, I don't think we should release this package in a strict cadence.

Okay, but this means the person releasing it will need access to our npm details. If we add a CI workflow we could trigger it manually, given we already have access to the credentials in CI

[boray]

How do you want to release this to npm, if at all?

We can release as a scoped package under o1js on demand similar to mina-signer.

Right, but manually or through CI?

Manually, I don't think we should release this package in a strict cadence.

Okay, but this means the person releasing it will need access to our npm details. If we add a CI workflow we could trigger it manually, given we already have access to the credentials in CI

I assumed you have the credentials for npm for o1js and you can release on my behalf. No worries, there won't be releases often :)

[Trivo25]

I assumed you have the credentials for npm for o1js and you can release on my behalf. No worries, there won't be releases often :)

We shouldn’t depend on a single person who may or may not have the credentials to release a package. For our other releases, we already have access to the credentials via CI, and we should follow the same approach here. Since we're introducing this new package to developers, we can expect feedback and requests for improvements - which means we'll likely need to release more frequently. Relying on one individual creates an unnecessary bottleneck and adds avoidable overhead to what could be a much simpler process.

[45930]

We shouldn’t depend on a single person who may or may not have the credentials to release a package. For our other releases, we already have access to the credentials via CI, and we should follow the same approach here.

Yeah, releasing the package automatically if the version is incremented seems best to me. How do we handle mina signer?

[45930]

I'm going to give this a ✅, but I would prefer (if we all agree) that we move this package to /packages/testing before landing this PR.

I think a separate PR is ok because the scope should also include migrating mina-signer (and o1js itself?) to the packages folder. I wouldn't want to muddy this PR with extra diffs and potential issues from that. We can handle migrating all packages to a standardized format in one PR.

[Trivo25]

How do we handle mina signer?

Same way. We can simply copy the workflow from here https://github.com/o1-labs/o1js/blob/d6ae829578ffaa1254ea53216db50c92a3f6274e/.github/workflows/build-action.yml#L286-L371