Proposal: improve TS experience when dealing with NodeJS APIs

[ernest-nowacki]

This PR is a proposal for improving DX experience when working with TS workflows and using unsupported APIs.

Context

Users are often thrown off guard and are presented with unreadable WASM traces when they use some of the NodeJS APIs that are not available in our Javy/QuickJS env. We would now change it to more readabile errors like this one:

That's a new compile-time check looking for imports of APIs like node:crypto, node:http etc.

We're also making changes to default tsconfig.json to NOT INCLUDE by default NodeJS types. What is being picked up however is our own custom types, marking APIs as never and deprecated. What it does in practice?

When you hover over imports in your IDE you would see suggestion to use our capabilities:

If you still decide to use particular API in the code itself you would see it crossed out:

If you run your bun typecheck you would also see TS errors:

It should give you a decent understanding of what's wrong compared to current experience.

How to test

New workflows

1. Expose extra command bun typecheck to verify types in your workflow.
2. Simulating will now look for restricted imports from node and error out - rather than showing wasm errors.

For pre-existing workflows:

1. Update your workflow package.json to point to cre-sdk@1.1.3-alpha.2.
2. Add types: [] in compilerOptions in your workflow tsconfig.json.
3. bun install.
4. Simulate.

Required

• Related TS SDK PR: remove node types and bun types from workflows cre-sdk-typescript#199
• Pre-release tag for testing: https://github.com/smartcontractkit/cre-sdk-typescript/releases/tag/v1.1.3-alpha.2

Next steps

This is just first step towards better use of TS for checking workflows. If this proposal is accepted we will continue making it better by exploring options to:

• bake typechecks into simulate / cli itself
  • current PR gives you optional bun typecheck we could make it required for the simulate / deploy tasks
• extend our import health checker to go into 3rd party libraries
  • for example if you import crypto-sha256 which under the hood uses restricted API we would like to catch that too
• make TS error out as soon as import happens
  • currently actual blocking TS error happens when you try to use unsupported module (for example: crypto.randomBytes(16)), it would be better if we could error out as soon as import { crypto } from 'node:crypto'