🧪 Announcing PicJS: TypeScript/JavaScript support for PocketIC!

[mraszyk]

@Vivienne

Using the real CMC is really not fun

This is how we bootstrap CMC in Orbit.

[NathanosDev]

@icme

For tests this isn’t as generally easy as a primitive mainly because of the cycle ledger setup in pic

I completely understand this, and it is possibly something that we could consider integrating directly into PicJS, but I can’t promise it any time soon.

@icme

I wasn’t able to get this to work, but here are the approaches that I’ve tried:

Hopefully the suggestions from Severin and Martin can help.

@icme

So I don’t follow how setupCanister() would fail with a low cycles error, but calling the provisional_create_canister_with_cycles directly successfully creates the canister with the intended cycle balance?

Just to add a bit more to Martin’s response to this, setupCanister() does three things:

• createCanister()
• installCode()
• createActor()

It’s the second step that is failing due to the low cycle balance.

[icme]

@NathanosDev

Yeah, this unfortunately won’t work with pic-js in it’s current state, but it’s possible to get it to work after it’s brought up to speed with the current server. I haven’t put any time into getting that extension to work, but it’s on my to-do list.

Just wanted to bump this in case any new PicJS features are being worked on.

[anon74414410]

Our JS devs are primarily doing agent-js features right now

[NathanosDev]

It’s on our roadmap and likely to be the next thing we work on once we shift focus back to pic-js.

[baolongt]

@NathanosDev Is that any example for deploy 2 canisters in different subnets

[NathanosDev]

Yes: pic-js/examples/multicanister at main · dfinity/pic-js

[theoman42]

Hey @NathanosDev , I am having some trouble with Pocket IC’s determinism.

I am creating two players and putting them in a map. The size of the map determines the index and default username of each subsequent new player.

When I create the first new player, Total Players increases to 1 as shown in the log, but when creating the second player, it somehow doesn’t recognize this updated map size and uses a stale state. Additionally, it doesn’t increase the Total Player count as shown in the log… Would be curious if this is due to how PocketIC handles global variables, not sure. Any help would be much appreciated!

[NathanosDev]

You are creating two different canisters. The 2nd call to createPlayerProfile goes to the 2nd canister, so it will not affect the state of the 1st canister.

You can do one of two things here.

• Use a single actor, but change the identity on the actor using actor.setIdentity() when you want to make a call as a different player.
• Create a second actor without creating a second canister using pic.createActor() instead of pic.setupCanister().

[theoman42]

I am getting this frustrating trap when I try to set up the the ledger for the icrc token. Is it a potential mismatch between the idl and wasm? Thank you in advance for any suggestions!

[NathanosDev]

Is it a potential mismatch between the idl and wasm

That seems to be the case, but it’s hard to say for sure. Did you find a solution yet?

[theoman42]

Not yet, I will revisit this week.

[theoman42]

Forgot init args, we are back in business!

[skilesare]

Is there a timeline for updating Pic.js to the agent 3.x?

[ilbert]

Currently, we don’t have a timeline.

Although, PRs are always welcome, and I’m available to help and review.

[peterparker]

Actually @ilbert and @skilesare, I was thinking - unless there is a reason why the test framework explicitly requires using the same version of the agent used by the dapps at runtime - it would maybe be ideal to migrate pic-js to be agent-js agnostic for its consumers?

At the top of my head, I would say this could be done either by making pic-js require agent-js as a peer dependency with any version allowed, or even better, by making pic-js standalone and bundling the agent within its shipped code (the bundle size does’nt matter much in this case, to some extent, since it’s not a runtime library).

But again, unless there is a reason why both are tightly coupled, which I don’t know.

[NathanosDev]

unless there is a reason why the test framework explicitly requires using the same version of the agent used by the dapps at runtime

There’s no reason to couple them. Only identity is used from @dfinity/agent.

I think making pic-js standalone is reasonable. We should also be able to achieve that by moving all the current peerDependencies to dependencies: pic-js/packages/pic/package.json at main · dfinity/pic-js.

[ilbert]

@dfinity/pic v0.14.0 has been released. We have bumped the @dfinity/... packages to v3 and removed them from the peerDependencies.

More info:

• PocketIC Version 10.0.0: bootstrapping system canisters
• New docs portal: js.icp.build/pic-js

[peterparker]

Thanks for the upgrade!

Nitpick: we missed discussed this in previous threads about the AgentJS dependency in Pic-js. If technically feasible, should the Pic types be migrated to use Uint8Array instead of ArrayBuffer for consistency between the two libraries?

[peterparker]

After upgrade to v10, one of my test suite — which runs in serial — was failing, and I resolved the issue by moving pic.setTime after the canister setup. So, out of curiosity, have I been doing it wrong all along?

beforeAll(async () => {
		pic = await PocketIc.create(inject('PIC_URL'));

        // I had to move this...
		// await pic.setTime(new Date('2025-05-12T07:53:19+00:00').getTime());

		const { actor: c } = await pic.setupCanister<ConsoleActor>({
			idlFactory: idlFactorConsole,
			wasm: CONSOLE_WASM_PATH,
			sender: controller.getPrincipal(),
			targetCanisterId: CONSOLE_ID
		});

        // ...here to resolve the issue
		await pic.setTime(new Date('2025-05-12T07:53:19+00:00').getTime());