pnpm monorepo lose type checking of the SDK during tests

[pradel]

Describe the bug

The SDK class is not properly typed when using clarinet in a pnpm monorepo. So calling the following code is not showing any error in the code editors where it should be having a TS issue.

const { result } = simnet.callReadOnlyFn("test");
expect(result).toBePrincipal("");

Also running pnpm tsc --noEmit is not reporting the error.
You can find a repo showing the problem here https://github.com/pradel/clarinet-pnpm-monorepo-issue.

To Reproduce
Steps to reproduce the behavior:

1. Clone https://github.com/pradel/clarinet-pnpm-monorepo-issue
2. pnpm install
3. cd apps/contracts
4. pnpm test is working but should be reporting a type error

Expected behavior

Report the type error.

Environment (please complete the following information):

• Clarinet version- 2.11.2

[hugocaillard]

Okay I'm learning.
From the pnpm doc:

The good thing about pnpm [...] by making it impossible to use modules that are not specified in the project's package.json.

The clarinet-sdk is taking advantage of this of this npm feature (use module that are not specified in the package.json), by requiring @hirosystems/clarinet-sdk-wasm (it's happening here). Which is a dependency of @hirosystems/clarinet-sdk

So as a possible workaround, you can add the following dependencies to the package.json

"@hirosystems/clarinet-sdk-wasm": "^2.11.0",
"@vitest/expect": "1.6.0",

I don't have a better solution for now.
What we could do on the sdk side would be to avoid this complex setup. One way to do it would be drop support for CommonJS in Clarinet@3.0 and simplify this alll setup. Which might be a good idea in 2025

This command has been helpful to debug the issue

$ pnpm tsc --listFiles

[pradel]

The fix is great for now thanks!
Going ESM only is a good idea 👍

[hugocaillard]

Closing this issue for now.
Will either add something in the doc for pnpm support or find a fix for early january / clarinet 3.0